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1. Introduction 


In the future, computer systems will be doing more of the tasks that are 
now performed by humans. The area of commercial avionics is no exception. 
Sophisticated computer systems will increase their share of the tasks involved 
in the control and flying of the aircraft. In order to make commercial aircraft 
of the 1990 's more efficient and profitable, new and advanced technologies will 
be used in their design and construction. Ways must be found to reduce the risk 
caused by these new technologies and thus to speed their acceptance. The 
Systems Validation Methods Branch in the Information Systems Division, is doing 
research in order to develop methods for fully integrating guidance and control 
functions, to identify system architectural concepts, and to establish a 
creditable validation process for advanced digital system designs. The 
contractor, PRC Kentron, is involved in this effort by providing support in the 
development of software to accomplish the latter goal, namely the development of 
methods for the analysis of the reliability of highly reliable, fault tolerant 
digital avionics systems. These advanced digital systems must be significantly 
more reliable than the systems now in use. What is generally meant by stating 
that the system must be highly reliable is that the probability that a system 
containing no failed components at the start of operation will fail during the 
first ten hours of operation will be less than approximately 10" 9 . It is clear 
that digital computer systems that are to be highly reliable must be fault 
tolerant. Fault tolerance is the characteristic of the hardware and software 
architecture which allows the system to continue operating correctly in spite of 
the occurrence of physical faults, i.e., the detection of faults and the 
recovery to normal operation is handled automatically by the hardware and 
software and does not require manual intervention. This detection and recovery 
must be carried out within a specified period of time and must be done 
concurrently with the controlling of the aircraft. 

Fault tolerant digital systems are implemented by first identifying the 
reliability goals of the system, and then selecting and incorporating fault- 
detection and recovery algorithms into the original design of both hardware and 
software. The tolerance to faults is usually accomplished with redundancy of 
components and algorithms which can reconfigure components in case of failures. 

Once a fault tolerant digital system has been constructed, an important 
problem is how to evaluate the reliability of the system. There are two 
approaches to this problem. One approach is the use of analytic modeling 
techniques. A second approach which can be used in conjunction with analytic 
methods, is the use of emulation techniques. 

This latter approach is currently being studied at the Langley Research 
Center. The idea being studied is that rather than basing reliability analysis 
on manufacturer's supplied data, or on expected probability distributions of 
failures of components to determine the response of a system to faults, a gate- 
level representation of the system is emulated. An algorithm has been developed 
to emulate any network of logic gates, flip-flops and tri-state devices. The 
algorithm is independent of the particular piece of hardware being emulated. A 
description of the particular target digital system is fed to a translator which 
converts the description to a form which the emulator can process. Hie 
processing of this representation of the target hardware by the software- 
implemented algorithm consists of the gate-level emulation of the target 
hardware. During this emulation, faults can be injected, and their effects 
studied. 

The particular algorithm was developed with a major objective being 
conservation of host time and memory. The speed is important because the target 
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system must be allowed to run for lengthy time periods, and the conservation of 
space is necessary because of the large number of gates, flip-flops, and tri- 
state devices in any modern digital system. The algorithm employs a general 
model for all types of gates, i.e., "AND", "OR", "NAND", "NOR", "NOT", "XDR", 
and a single generalized model for all types of flip-flops. These general 
models allow for efficient use of computer memory. Time is conserved by 
processing only those devices in a given cycle whose input(s) have changed 
during the previous cycle. 

This algorithm allows for the insertion of faults into the system, and for 
the observation of the response of the system to these faults. This allows for 
controlled and accelerated testing of system reaction to hardware failures in 
the target machine. 

As an initial experiment, a horizontally-microprogrammable computer, the 
Nanodata QM-1, was chosen as the host system. The emulation algorithm was coded 
at the microcode level to take advantage of the parallel capabilities of the 
host machine and to exploit the speed advantages of executing code at the most 
primitive level of the host computer. All preprocessing of the hardware 
description and fault-injection data, as well as all post-processing of fault 
data is performed on a Digital Equipment Corp. VAX 11 which is interfaced to the 
QM-1. 

The emulation algorithm has been used to emulate a simplified model of a 
"Toy" computer, the central processing unit of the Bendix BDX930, and the 
communicator interstage unit of the Fault Tolerant Processor, working emulators 
are resident in a QM-1 computer and a Vax computer in AIRLAB, the Avionics 
Integration Research Laboratory, at the Langley Research Center. These 
emulators will be used as general reliability analysis tools for highly 
reliable, fault tolerant avionics system. A complete and detailed discussion of 
the concepts inherent in the technique is given by Migneault[2] . The remainder 
of this document will describe in detail how the algorithm was implemented at 
NASA/LaRC and instructions on how one goes about using the system. 
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2. General Description 

2.1 Overview: General Principles and Assumptions 

The Diagnostic Emulation Technique is a general technique which allows for the 
emulation of a digital hardware system. The technique is general in the sense 
that it is completely independent of the particular target hardware which is 
being emulated. A description of the hardware to be emulated is presented to 
the emulation program in the form of input data. 

The technique is a hybrid one in that parts of the system (the network) are 
described and emulated at the logic or gate level, while other parts of the 
system (the functional subsystem) are described and emulated at the functional 
level in order to save time and unnecessary complexity. It is up to the user 
of the emulation program as to which parts of his system are to be emulated at 
the gate level and which parts are to emulated at the functional level. 

The network to be emulated at the gate level consists of a set of devices 
(gates, flip-flops, and tri-state devices), and a set of connections among 
these devices. 

Each input and output to or from a device may assume one of two values, namely 
high ( represented by 1 ) or low ( represented by 0 ) . 

The basic unit of time(t) used by the emulator is the time it takes for the 
input signals on a logic device to be propagated through to the output of that 
device. It is assumed in this technique that the propagation time for all 
devices in the network is the same and remains constant throughout the 
emulation. This is not an inherent limitation of the diagnostic emulator, 
although unit delay is assumed for this implementation. 

The technique allows for a very flexible method in which the gate-level network 
and the functional subsystems can communicate with each other. This method 
also allows the user to define any type of subsystem he wishes as long as he 
can describe it in terms of a data structure and a subprogram module that 
operates on the data structure and optionally also operates on the gate level 
network . 

The state of the entire system at any given time consists of state descriptions 
of all logic devices in the network, state descriptions of all connections 
among devices, and a state description of the functional subsystem. The 
emulator must have given to it at t«l the initial state of the entire system. 
The emulation then consists of a series of iterations, one for each time step. 
Given the current state of the system at time T, the emulator calculates the 
new state of the system at time T+l. It continues these iterations until it 
reaches the stop time specified by the user. 

The emulation technique is event-driven in the sense that for a given 
iteration, only those logic devices are processed whose output values have 
changed during the previous iteration. 

Important functional capabilities which have been incorporated into the NASA 
LaRC implementation are: the ability to insert and/or remove stuck-at faults 

at user-specified times into the logic gates and/or into the ROMS, the ability 
to input to the digital logic at user-specified times from sources external to 
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the simulation, and the ability to output from emulated logic to sources 
external to the emulation either at user-specified equally spaced time periods 
or at times controlled by the internal logic. Hie technique and its concepts 
are basically independent of any particular implementation. All of the 
characteristics which have been described above are general concepts of the 
technique and are independent of any particular implementation. The overall 
structure of the technique is depicted in Figure 1. 


Initialize 

System 





Program Step 


J Data File 


t 



Overall Structure of the Technique 

Figure 1 
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3. System Structure 

The emulation system as it has been implemented at NASA/LaRC consists of 
two parts. The first part is the "Initialization" system which calculates a 
consistent initial state for the target hardware and generates this initial 
hardware state in the binary form required by the second part. Part 2 is the 
emulator. The emulator begins with the initial machine state and performs the 
emulation as per the user's specifications. 

The initialization program requires as input a description of the gate- 
level network in the Diagnostic Emulator Netlist Format (DENF) , and a list of 
the initial contents of any memories being emulated at the functional level, in 
the Diagnostic Emulator Memories Format (DEMF) . The Initialization Program is 
described in detail in Section 5.4.1. It is the user's responsibility to 
provide these two required inputs to the initializer in the formats required. 

It is thus necessary for the user to provide some sort of "preprocessor" to 
generate the netlist in DENF format and the memories in DEMF format. To date, 
two preprocessors have been developed to provide these descriptions to the 
initializer in the required format. The first was developed at NASA for the 
CYBER computers in the Analysis and Computation Section and uses a NASA- 
developed netlist language for its input. The second preprocessor was 
developed by the Research Triangle Instituted ] and uses Futurenet as its input 
language . 

This document does not include any discussion of preprocessors. A 
complete description of the DENF and DEMF formats is given in Section 5. 4. 1.2. 
Thus a user can generate his own translator or preprocessor to translate from 
the language of his network description and from his memory format to the 
required formats. 

The initialization program produces the complete network description and 
the memories' contents in the binary form required by the emulator. In 
addition, the initializer calculates (if possible) a consistent initial state 
for the entire system. 

The emulator then uses the initial machine state generated by the 
initializer together with other user-supplied information to perform the 
emulation. 


3.1 System Flow of Control 

The overall program and data flow for the preprocessor, initializer, and 
emulator are shown in Figure 2. The general idea is that for a given target 
machine to be emulated, the preprocessor and initialization systems need be run 
once (or several times if errors or inconsistencies exist), i.e., until the 
system is successfully initialized. At that point the initial state of the 
system has been saved in a binary form for the emulator, and the emulator can 
be run as many times as desirable, varying its inputs, without having to rerun 
the preprocessor or initialization systems. 
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3.2 Emulation Flow of Control 


One of the user-supplied inputs to the emulator is the "Fault File". Hie 
data in the fault file controls the emulator. All the data in one fault file 
is referred to as a "Batch". The fault file consists of any number of 
individual fault lists, each of which causes one "Run" to be executed. A "Run" 
is an emulation which begins at time t-1 and continues until a user-specified 
stop time. An individual fault list describes when and what kind of faults are 
to be inserted for the run, and when the run is to stop. Each run in the batch 
begins by re-initializing to the initial state as defined by the initialization 
program. Each run makes use of the same external inputs file. Hie differences 
from one run to another within the same batch are caused by the different fault 
list for each run. Hie fault file is described in detail in Section 5. 4. 2. 2. 3. 
Hie batch is completed when all fault lists have been processed, or in other 
words, when the last run has completed. In summary, a batch consists of many 
runs. For each run the gate-level network and the functional subsystems are 
the same. Hie initial state of the machine and the external inputs are the 
same. Hie faults injected and the stop time may vary for each run. Hie flow 
of control during which the emulator processes one batch is shown in Figure 3. 
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4. Implementation of Diagnostic Emulation Technique 
4.1 Overview of Implementation 

The Nanodata QM-1 computer is a high-speed general-purpose digital 
computer. It was chosen for the first implementation of the Diagnostic 
Emulation Technique because at the lowest level it is horizontally 
nux reprogrammable. See the QM-1 Hardware Level User* s Manual [ 3 } for a detailed 
description of the QM-1 architecture . It should be noted that the QM-1 at 
NASA/LaRC contains three levels of memory. At the highest level is the main 
store memory which consists of 500K of 18-bit words. The control store memory 
consists of 40K of 18-bit words. At the lowest level is the nanostore which 
consists of IK of 360-bit words. Microcode is stored in the control store, 
while nanocode is stored in the nanostore. 

The emulator was implemented on the QM-1 as follows: The algorithm which 

emulates the gate-level logic was written in nanocode at which level the 
primitives of the QM-1 hardware are controlled in a parallel manner, i.e. , 
during each t-step of the QM-1 many different nanoprimitives may be executed 
simultaneously. The QM-1 has a nanoassembler which was used to assemble the 
nanocode which implements the gate-level emulation algorithm. The algorithm 
which performs the functional parts of the emulation was written in microcode 
(on the QM-1, each microcode instruction is carried out by a sequence of 
nanocode instructions and is therefore one level higher than nanocode). The 
microcode language used was "Multi", and the functional algorithm or "Driver" 
was assembled with the Microcode Assembler. Two new microcode instructions, 
namely "Emul" and "lemul" were defined as extensions to the "Multi" language, 
and when used in the Driver, cause the appropriate parts of the nanocoded gate- 
level algorithm to be executed. "lemul" causes the initialization of the gate- 
level data structures to be carried out, and "Emul" causes one time period or 
one stack of the gate-level network to be processed. Both of these multi- 
extension codes then appear as instructions in the microcoded Driver. The 
nanocode and microcode are combined into an executable form as described in 
Section 5.1.2. 

The front end program for the emulator, namely the Initialization program, 
was written for the Vax 11 in Fortran. Because of the need to check the 
results of the QM-1 emulation, an emulator was also written in Fortran to run 
on the Vax. The Vax emulator was naturally much simpler to write than the QM-1 
emulator but runs about 36 times slower than the QM-1 implementation. The 
result is that the user now has two options as to how he will run the emulator. 
He must run the Initializer on the Vax, but then has the choice of whether to 
do the actual emulation on the Vax or on the QM-1. The user must weigh the 
disadvantage of the added complexity of using the QM-1 against the advantage of 
the gain in speed. It should be pointed out that the QM-1 emulator was 
implemented first, and that the Vax emulator was written to conform to the QM-1 
18-bit word, and has basically emulated the control store and main store of the 
QM-1. 


4.2 Models 

4.2.1 Gate-level Network Model 

Any network to be emulated at the gate level consists of a set of gates, flip- 
flops, and tri-state devices, and a set of the connections among these devices. 
Any input or output to or from a device may assume one of two values, namely 
high (represented by 1) or low (represented by 0). 
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4.2. 1.1 Simple Gates 

A gate may be any of the following types: AND, NAND, OR, NOR, NOT, XOR, NXOR. 
Normally, a simple gate is enabled; however, the faulting of a gate (output 
stuck at 1 or 0) is implemented by disabling the gate. 


4.2.1. 2 Tri-State Devices 

A tri-state device is any of the simple gates listed above, but in addition has 
an enable/disable input. Hie internal value (namely the output value 
consistent with the inputs) of the tri-state device is always kept current, 
but if the device is disabled, its internal value will not be propagated to its 
output line, but rather its output line will be stuck at either 0 or 1 (the 
value chosen by the user in the netlist for that particular tri-state device) 
until the tri-state is enabled. 

4.2.1. 3 Flip-Flops 

A general model for a flip-flop is used by the algorithm. Note that a flip- 
flop is not modeled at the gate level. The general model for the flip-flop is 
as shown in Figure 4. 


4-4 4-4 


> 

> 


P C T L 

J Q 

K 


•> 


P preset 
C clear 

T clock trigger 
L latch 
J input 1 
K input 2 

D D connection 1 
R indeterminant flag l 2 
u indeterminant flag 2 2 


1 A "D" connection is merely one in which the K input is always 
the complement of the J input. 

2 See A-29, Legends for Internal Connectors, 

A-6, Flip-Flop Trigger Chart, and Migneault[2] 

Flip-Flop Model 

Figure 4 


By using these lines appropriately, all of the useful edge-triggered types of 
flip-flops can be modeled, as described by Nigneault[2] . Note that this model 
accomodates only one output, namely the Q output. If the QBAR output is 
desired, it can be obtained by adding an additional flip-flop with the inputs 
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reversed from those of the Q flip-flop. See A-42 for an example of a Q, QBAR 
flip-flop set. The preset and clear lines for all flip-flops in a network can 
be active high or active low, as defined by the user. Note, however, that all 
flip-flops in a network must be either active-low or active-high. The clock 
trigger for each flip-flop can be either upward edge-triggered or downward 
edge-triggered, again as specified by the user. In this case, however, the 
choice for each flip-flop is individually controlled. For each device in the 
network, a data structure exists which at all times reflects the state of that 
device. 


4. 2. 1.4 Event-Driven Feature 

The emulator technique is event driven; that is, during each time period a 
given device will be processed only if a specific event has occurred during the 
previous time period, namely that device's output value has changed. Any 
device whose output value did not change during the previous period need not be 
examined since it cannot affect any other device. 


4.2.2 Functional Subsystem Model 

Any subsystem which is to be emulated at the functional level is 
implemented with a data structure (called an action data structure) 
representing its state at any given time, and with an action subroutine module 
which performs the specified function. Some examples of functional emulations 
which have been implemented on this system are ROMS, RAMS, fault injection and 
removal, external inputs to the network, and external outputs from the 
network . 

In order to implement functional emulation, event scheduling is used, 
while the gate-level network emulation is synchronous in the sense that at each 
time interval the devices are processed whose output values changed during the 
last time step, the functional emulation is asynchronous in that functional 
events do not necessarily occur at fixed time intervals and therefore must be 
scheduled. To provide for this, two data structures are used. An event list 
contains all events currently scheduled to be executed at specific times, and a 
free space list contains a list of memory slots currently available for use by 
the event list. Because the number of scheduled events grows and shrinks, 
there is dynamic allocation of space between the two lists, i.e., space is 
taken from and returned to the free space list according to the space 
requirements of the event list. Each event scheduled points to the head of an 
action list. Each action in that list is to be executed at the time specified 
in the event. 
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4.3 Data Structures 


4.3.1 External Registers 

In general, external registers are used when data is to be communicated 
between the gate-level emulation and the functional emulation. Hie user may 
direct that the emulator set up a block of contiguous external registers in 
control store and/or a block of external registers in the main store of the QM— 
1. Each external register is an eighteen-bit word in the QM-1 memory. Each 
block of external registers, no matter where it may be in the QM-1 memory, for 
the user's purposes, is labeled beginning with register number 1, and the rest 
of the block is numbered consecutively. 

An external register can receive its value in two different ways. The 
user can specify in the netlist that the output of any particular device in the 
network feed into any bit(s) in one or more external registers. Thus during 
the emulation the bit in the external register at all times is a copy of the 
output line of the associated device. This is a technique for collecting in 
one contiguous group of bits in the QM-1 memory, the output values of any 
selected set of devices. This use is shown in Figure 5. 

An external register can also receive its value from the functional 
subsystem emulation during the execution of an "action", and typically could 
then be used by any other action. An example of the use of external registers 
is the data and address registers used in the implementation of memory reads 
and writes. See Figures 9 and 10 for illustrations of these uses. 
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4.3.2 Network Connections 

There are two types of connections within a gate-level network, namely 
internal connections and external ("pseudo") connections. An internal 
connection is one which goes from the output of a network device to the input 
of a network device which may be the same device as the source device or a 
different one. In any case, both the source and destination of an internal 
connection are devices within the network. In the case of an external 
connection, the source is a device within the network, but the destination is 
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an external register in that it does not exist within the network being 
emulated, but is a register in the QM-1 created as a means for implementing the 
functional part of the emulation. An external connection is then one which 
goes from the output of some device in the network to a specified bit in some 
external register. Once this connection is set up in the netlist, then during 
the emulation the bit in the external register at all times is a copy of the 
output line of the associated device. Thus this is a technique for collecting 
in one contiguous group of bits in the QM-1 memory, the output values of any 
selected set of devices. External register connections are defined by the user 
in the netlist and may be used for any functional subsystem desired. To date, 
they have been used to implement memory reads and writes by emulating the data 
and address registers and for external inputs and outputs, again by serving as 
the data registers. They are also used in memory reads and writes and external 
outputs by holding the values on the control lines which then are used to 
trigger the particular action. Figure 6 shows diagrams of both types of 
connections. 
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4.3.3 Hardware Description Matrix 

Hie hardware description matrix is a binary representation of the entire 
network of devices and interconnections among the devices. Hus description of 
the network of gate-level logic is represented in the control store of the QM-1 
by a set of Device Records , each record representing one device in the target 
network. A device can be a gate, flip-flop, or tri-state device. The device 
records need not be in any particular order. 

Each device record is made up of exactly one Header word, followed by one 
or more internal connector records, followed by zero or more external connector 
records. The Header word fully describes the state of the device at any given 
time. The format for a particular Header word varies depending on the type of 
device. The formats for the various types of devices is shown in A-25. An 
internal connector record describes a connection from the output of this device 
to the input of another device in the network. An external connector record 
describes a connection from the output of this device to an "external register" 
which is pseudo in that it does not exist in the real target network, but is 
used for implementation of functional emulations. The components of a device 
record must be in the order stated above, and they must be contiguous. The 
connector records for a particular device may be in any order, and the pseudo 
connector records may be in any order. The overall structure of the Hardware 
Description Matrix is shown in Figure 7. 
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4.3.4 Stacks 

The emulator gate-level technique is event driven; that is, during each 
time period a given device will be processed only if a specific event has 
occurred during the previous time period, namely that device's output value has 
changed. Any device whose output value did not change during the previous 
period need not be examined since it cannot affect any other devices. The 
method used to efficiently implement this event-driven capability is the 
maintenance of two stacks. At any given time, one stack is identified as the 
"c" stack, and the other is referred to as the "cbar" stack. During each 
time period, the list of devices which changed during the previous period is 
known as the c stack. The emulator takes one device at a time, namely the 
source device, off the c stack and processes it. For each source device, it 
examines each destination device into which this device feeds, as it is a 
possible candidate for a change in output value this time period. If the 
destination device does not have a change in output value, the emulator 
proceeds to examine the next device into which the source device feeds. If the 
output value of the destination device does change, it is added to the list on 
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the cbar stack. Thus it can be seen that at the end of this time period, the 
cbar stack contains a list of all devices whose output values have changed 
during this time period. A device placed on the cbar stack may have changed 
output value an even or odd number of times during this time period. If it 
changed an even number of times, it is not processed during the next time 
period. As part of the initialization for the next time period, the time is 

incremented by one, the cbar stack now becomes the c stack, and the previous c 

stack becomes the new cbar stack, and is cleared, to be built up again during 
the new time period. Thus it can be seen that the program is always reading 
the c stack and writing the cbar stack, and also that the identity of the two 
stacks reverses itself each time period. It has been observed that for any 
given time period, only a very small percentage of the devices in a network 
need be examined. 

At the start of each emulation run, stack c must contain the device 
identifiers for all devices whose output values changed during the previous 
time period, namely t«0. At the end of processing for the first time period, 

stack cbar contains the device identifiers for all devices whose output values 

changed during this first period. The stacks are then reversed after each time 
period. The identifiers on the stack are not in any particular order. The 
program maintains a pointer to the base and top of each stack. Each stack 
grows upward to a higher control store location, i.e., as a device is added to 
the stack, it is pushed onto the top of the stack and the top of stack pointer 
is incremented. As each device is processed, it is popped off the top of the 
stack, and the top of stack pointer is decremented. At the beginning of each 
run, stack c must contain at least one device identifier, and stack cbar 
contains no identifiers. Figure 8 shows the general structure of a stack 
beginning at control store location x and containing n devices: 
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4.3.5 Events 

Events which are emulated at the functional level must be scheduled 
because they do not necessarily occur each time period. To implement this 
scheduling of events, two singly-linked lists are used, namely the event list 
and the free space list. Both lists are maintained in the control store of 
the QM-1. A pointer to the head of each list is also maintained in control 
store. Each element in the event list is a record consisting of three words. 
The first word contains the time at which the event is to be executed or 
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emulated. The second word contains a pointer to the next event in the event 
list which is to be executed at some time greater than the time for this event. 
The links in the event list are maintained so that the list is always in 
ascending time sequence. The last event in the event list contains a null (0) 
pointer in the second word. The third word in the event list is a pointer to 
the first action in control store which is to be executed at this time. The 
actions are also maintained in a singly-linked list, so that many different 
actions may be executed at one specified time. An action list is in the 
reverse order to that in which the actions were scheduled. The format for the 
event list data structure is shown in A-2, and a diagram showing the event list 
as it relates to the free space list and the action list is shown in A-l. 
Scheduling of events and actions is shown in A-4 and A-5 respectively. 


4.3.6 Actions 

Each unique functional subsystem is implemented through the use of an 
"action". An action is composed of an action subprogram module, an action data 
structure, and optionally other data structures required for the particular 
action. In general, when the time period occurs for which the action has been 
scheduled, the specified action subprogram is given control, and it "executes" 
the action by making use of the corresponding action data structure(s) . 

There must be in the QM-l's control store memory one action record for 
each unique action be performed. The number of words in each action record 
varies according to the type of action; however, each action record contains at 
least three 18-bit words. The format of the first three words is the same for 
all actions. The remaining words, if any, vary according the action. 

At any particular time, an individual action is scheduled to be executed, 
or not, as indicated by the "scheduled" switch in word 1 of the action. If it 
is not scheduled, it is not linked into any of the action lists. If it is 
scheduled, the appropriate pointers link it into the action list for the event 
scheduled for the time at which this action is to be executed. 

The importance of the actions feature in the scheme of the diagnostic 
emulator cannot be overemphasized. Associated with each action data structure 
must be a subroutine module which is to be called when the time period is 
reached for which the action has been scheduled. 

To date, six different action subprograms are available to the general 
user of the emulator. These actions are: write to memory, read from memory, 

stop run, "do operations", do external inputs, and do external outputs. Each 
of these actions is described in detail in Section 4.3.10. In addition to 
these supplied actions, the fact that the user can write as many of his own 
actions as desired is the feature which makes the emulator so flexible. The 
implication is that any functional emulation which can be written in subprogram 
form by the user can then be used in conjunction with the gate-level emulation. 
Thus it is possible for an action written by a user at the functional level to 
actually access and/or modify the state of the gate-level network. It should 
be noted that there is not necessarily a one-for-one mapping between the action 
data structures and the action subprograms. Typically, there may be many 
action data structures associated with one subprogram. For example, there is 
one read action subprogram, but there must be one memory control block, one 
emulated memory, and one action data structure for each ROM or RAM to be 
emulated. The subprogram performs the actual read action but the action data 
structure specifies the location of the memory to be read, the size of the 
target word, the locations of the data and address registers, etc. In other 
words, the subprogram is general for most reads, but the action data structure 
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is specific to the memory. It is usually possible for all the memories to make 
use of the same read memory subprogram. The same is true for the write memory 
subprogram. 

4.3.7 Master Action Control Register 

For each target emulation, one external register, namely the "action 
control register" must be designated to control the triggering of any actions 
associated with functional subsystem emulation. The high-order bit of this 
register is the master action control bit for all actions. Each device which 
controls the triggering of an action should have an external connection into 
the high-order bit of the action control register, in addition to having an 
external connection into some control bit in the action control block. For 
each time period, the emulator checks the high-order bit of the master action 
control register. If it is on, the emulator knows there is at least one action 
to be scheduled, and proceeds to check all the bits in control bit words of the 
action control block. For each bit in the control bit word which is on, the 
appropriate action is scheduled. On the other hand, if the high-order bit of 
the master action control register is off, the emulator knows that no actions 
are to be scheduled and need not check the individual control bit words of the 
action control block. 

4.3.8 Action Control Block 

For all functional subsystems (actions), a set of action control blocks is 
allocated in the control store of the QM-1. Each block will contain one or 
more action control records. There is one action control record for every 
eighteen action control lines. An action control record consists of one word, 
referred to as the "Control Bits" word, to represent the values of the eighteen 
control signals (this word is actually a "pseudo" register which is fed by 
appropriate devices in the netlist), and two additional words for each control 
line. The last action control record may not actually represent a full 
eighteen control lines, but the full amount of storage (37 words) is allocated 
in any case. The data structure for an action control block is illustrated in 
A-3. Note that words 1 through 37 will be repeated contiguously until all 
action control lines for which actions can be scheduled have been accounted 
for. 

When the emulator has determined that the master action control bit is on, 
it proceeds to check each bit in the "control bits" word. When it finds a bit 
that is on, it accesses the appropriate two words in the action control record 
for the address of the corresponding action and the appropriate delta time. It 
then schedules the action whose address it has accessed to be executed at a 
time equal to the current time plus the delta time it has accessed. 


4.3.9 Emulated Memories 

A contiguous block of main store in the QM-1 is allocated for each ROM or 
RAM to be functionally emulated. Each QM-1 main store word contains eighteen 
bits. The number of QM-1 words necessary to represent one target memory word 
depends completely on the number of bits in the target word. If the target 
word has 18 or less bits, then only one QM-1 word is needed for each target 
word. In any case the target bits are stored in the QM-1 with the highest 
order target bits stored in the high order bits of the lowest QM-1 address 
used. The target word may be stored in the QM-1 either right or left 
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justified, as determined by the user. It is not necessary for two or more 
memories to be contiguous to each other in the QM-1, but within one memory, all 
QM-1 words are contiguous. See A-33 for a layout of the memory data structure 
and A-34 for the Emulated Memory Layout. 

4.3.10 Action Descriptions 

Following are descriptions of the actions which have been implemented to date: 

4.3.10.1 Write Memory Action 

The write action is used to write a word from a data register to a target 
word in ROM or RAM. See A-36 for the Write Memory Action Data Structure 
Layout. The action is scheduled when the controlling device transitions from 
low to high. The action is scheduled at a time equal to the current time plus 
the delta time in the second word of the write action data structure. 

When the current time reaches the scheduled time, the write action is 
executed. The emulator reads the emulated address register and shifts the bits 
the appropriate amount to right- justify the target address. Next it checks 
this address against the low and high valid target addresses in the seventh and 
eighth words of the action data structure. If the address is not within this 
valid range, a message is outputted, and the program aborts. If the address is 
valid, the actual QM-1 address for the target word is calculated as: 

QM-1 address - relocation constant + 

target address * number of QM-1 words per target word 

(The number of QM-1 words per target word is obtained from the first word of 
the action data structure, and the relocation constant is obtained from the 
fourth word of the action data structure). The program then reads the data 
register as pointed to by the sixth word of the write action data structure. 

It then stores the data from the data register into the QM-1 address as 
calculated above. This procedure is repeated for all QM-1 words representing 
the one target word. Figure 9 is a diagram of a write memory action structure. 
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4.3.10.2 Read Memory Action 

The read action is used to read a word from a target ROM or RAM. See A-37 
for the Read Action Data Structure Layout. The action is scheduled when the 
controlling device transitions from low to high. The action is scheduled at a 
time equal to the current time plus the delta time in the second word of the 
read action data structure. 

When the current time reaches the scheduled time, the read action is 
executed. The emulator reads the emulated address register and shifts the bits 
the appropriate amount to right- justify the target address. Next it checks 
this address against the low and high valid target addresses in the seventh and 
eighth words of the action data structure. If the address is not within this 
valid range, a message is outputted, and the program aborts. If the address is 
valid, the actual QM-1 address for the target word is calculated as: 

QM-1 address - relocation constant + 

target address * number of QM-1 words per target word 

(The number of QM-1 words per target word is obtained from the first word of 
the action data structure, and the relocation constant is obtained from the 
fourth word) . The program then reads the appropriate QM-1 address to get the 
new data. It then compares this new data, bit by bit, with the old data in the 
data register pointed to by word six of the action data structure. In each 
case, if the bit in the target word just read agrees with the bit in the data 
register, no action need be taken; however, if the bits are different, then the 
device in the network (as specified in the appropriate word in the action data 
structure) to which this bit feeds is enqueued on the stack. This procedure is 
repeated for each bit in this word, and then the entire procedure is repeated 
for all QM-1 words representing the one target word. Each word of the data 
register is then updated to represent the data just read from the target 
memory. It should be noted that for a read memory action, the devices into 
which the bits in the data register feed must be simple gates. Figure 10 is a 
diagram of the read memory action structure: 
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4.3.10.3 Operations Action 

The "Operations Action" was created to allow the user to control, at run 
time, when and how certain functionally emulated "operations" are to be 
performed. See A-39 for the action data structure used for the operations 
action. Each valid operation has been assigned a particular operation code. 

To date, the valid operations codes are: 

Code Operation 

2 stop run 

3 stick gate at 0 

4 stick gate at 1 

5 lift gate fault 

6 insert fault in ROM 

7 lift fault from ROM 

For each batch job, these operations are specified by the user in the Fault 
File. See Section 5. 4. 2. 2. 3 for a detailed discussion of the fault file. The 
"operations action" is the method used for implementing these valid operations 
at the properly scheduled times. The implementation works as follows: At run 
time, the fault file for the entire batch is read and converted to the "fault 
buffer" which is stored in the main store of the QM-1. For each op code in the 
fault file, the user has specified a time at which it is to be scheduled, and 
possibly other parameters, depending on the particular op code. In the control 
store of the QM-1, are maintained two pointers. The first (pi) points to the 
first word of the fault buffer and remains unchanged for the duration of the 
batch execution. The second pointer (p2) always points to the next entry in the 
fault list to be scheduled. For each run in the batch, the operations must be 
entered in the fault list in ascending time sequence. During initialization 
for each run, the emulator schedules the first operation for that run. When 
the emulator reaches the time period at which at least one operation has been 
scheduled, it executes all actions which have been scheduled for that time. It 
then adjusts pointer p2 appropriately and schedules the next operation. Since 
each run must have a "stop run" as its last operation, this is the manner in 
which multiple runs are carried out for each batch. Figure 11 shows the fault 
buffer format. 
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Following are descriptions of the op codes which have been implemented to date. 

4.3.10.3.1 Stop Run 

When a "stop run" is executed, a switch is turned on which causes the main 
program to terminate processing for that run. 

4.3.10.3.2 Stick Gate at 0/1 

For the purposes of sticking and lifting stuck-at faults from gates, a 
dummy gate must be added by the user as the last gate in the network. See 
Section 5.2.3. When any gate, say gate X, is faulted, the program dynamically 
creates a temporary connection from the output of the dummy gate to the enable 
input of gate X, sets this line to "disabled", and simultaneously sets VDIS 
(see A-29) in the connector word to the value at which the gate is to be stuck. 
Itiis causes the gate to be disabled, and its output equal to VDIS, in essence 
causing the gate to be stuck at the desired value, until a "lift gate fault" 
operation is scheduled for that gate. 


4.3.10.3.3 Lift Gate Fault 

In order to lift a gate fault, the connection that was established between 
the dummy device and device X when the gate was faulted, is removed, and the 
gate is thus enabled and its output will again reflect its inputs. 


4.3.10.3.4 Insert Fault in ROM 

The user specifies the number of the RON, the address and the bit position 
to be faulted. Hie emulator merely complements the bit which is to be faulted. 




4.3.10.3.5 Lift Fault from ROM 

Again the user specifies the number of the ROM, the address and the bit 
position from which the fault is to be lifted. The emulator merely complements 
the bit, thus returning it to its correct value. 


4.3.10.3.6 Stop Batch 

This operation is unique in that it may not be specified by the user. The 
program automatically adds a "stop batch" code at the end of the fault buffer. 
When it is executed, a switch is set which causes the main program to terminate 
execution of the entire batch. 

4.3.10.4 External Inputs Action 

The emulator contains a feature which allows the user to request that 
inputs generated externally from the emulation be inserted into network devices 
internal to the emulation, at specified times. This feature is implemented 
with the external inputs action. For a given batch, a user may specify any 
number of external input sets, or he may request none. Each set corresponds to 
a particular set of devices in the network. Each set consists of a set of 
contiguous input data bits coming from an external source to be inserted into 
the set of specified devices in the internal logic network. The user decides 
how he wishes each set to be composed, i.e., for each external input set, he 
decides into which group of devices in the network and in which order the 
external inputs are to be fed. He also specifies at what times these input 
signals should be inserted. For each external input set that is specified, a 
separate external input file must be generated by the user before the emulation 
begins. This file contains a list of external input items. Each item consists 
of a time at which the data is to be inserted into the devices and the data (a 
contiguous set of l's and 0's) which is to be inserted at the given time into 
the given devices. For a given batch, the same external input data is used for 
each run. 

During batch initialization, the program reads the external input files 
and creates in the QM-1 main store a contiguous list of the data from these 
files, where this list consists of a sublist for each external input set. 

These sublists are re-used for each run, so that, for a given batch, the same 
external inputs are used for each run in the batch. The program also creates 
an external input action for each one of these sets. A pointer to this main 
store list is put into the appropriate action. The program also sets up a 
contiguous set of address and data registers for each external input set. For 
the purposes of setting up these structures, the user supplies to the 
initializer the address of the control store location for the first external 
inputs action data structure, the control store address for the first data 
register and the control store address for the first address register 
associated with the external inputs action. 

The external inputs action is implemented in a manner similar to the read 
action, except that it is not triggered by a control line, but rather by the 
current time reaching the time specified in the external inputs file. Also, 
the external inputs action automatically increments the appropriate address 
register to point to the next data item and also schedules the next external 
inputs action for this set. The action data structure as well as the data 
registers and address registers needed are created by the program, and are 
basically transparent to the user, with the exception that he must specify 
where in the memory of the QM-1 these data structures will be placed. The 
first external inputs action for each external inputs set is scheduled at the 
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beginning of each run, and then immediately after any external input action is 
executed, the next one in time sequence for that run is scheduled. 

For each set, the user supplies the name of the associated external inputs 
file, the number of bits in the data, and the names of the devices to which the 
data feeds. These devices must be single input gates or single-input tri- 
states, i.e., for a regular gate there must be no input to the gate other than 
this external one, and for a tri-state, there must be no input other than the 
enable/disable line. Figure 12 shows the structure for the external inputs 
action. 
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4.3.10.5 External Outputs Action 

The emulator contains a feature which allows the user to request that the 
output signals from specified devices in the network be recorded or "externally 
outputted" at specified times, and in specified groupings. This feature is 
implemented with the external outputs action. For a given batch, a user may 
request any number of external output sets, or he may request none. Each set 
corresponds to the output signals from a specified set of devices in the 
netlist. For each external output set that is requested, a separate external 
output file will be written at the completion of the batch. The user decides 
how he wishes each set to be composed, i.e., for each external output set, he 
sets up a group of external data register! s] into whose bits he feeds the 
signals he wishes to output in whatever order he wishes them to be arranged. 

He also specifies at what time periods these output signals should be captured. 
They can either be captured automatically at regular time intervals, or the 
capturing of data can be triggered by logic internal to the network. Thus when 
the batch is completed, each external output file will contain one record or 
entry for each time the external output action was triggered. Within this 
record will be the time at which the data was captured and the data itself. As 
an example, if the target hardware contains an accumulator whose contents the 
users wishes to track, he would feed the devices representing the bits of the 
accumulator into external register! s] and would use these external register! s] 
to create an external output file. By reading this external output file, he 
would see at specified times the contents of the accumulator. Note: for one 

external output set, all the bits in the external registers to be outputted 
must be contiguous and can occupy more than one QM-1 word; however the bits for 
one external output set (the data register! s]) do not need to be contiguous 
with the bits for a different external output set. 

The implementation for an external output set is done as follows: During 
batch initialization, the program reads all the data necessary to create an 
external outputs action for each external output set. The emulator sets up the 
necessary action data structure for each external output set requested. The 
appropriate pointers are put into the appropriate action. The program also sets 
up a contiguous set of address registers, one for each external outputs set. 

The program automatically maintains the address registers, but it is the user's 
responsibility to maintain the data register for each external output set. The 
initializer reads the control store location for the first external outputs 
action, and the control store address for the first address register. For each 
set, the emulator reads the number of bits in the data, the name of the output 
file to be produced, the maximum number of data items in the buffer, the 
control address of the associated data register, the reschedule flag, the start 
time and the delta time. The external output generated can be triggered by a 
control bit or by automatic rescheduling, depending on how the reschedule flag 
is set. If the reschedule flag is 0, the scheduling is done by the internal 
logic using a control line (handling this in the same manner as a memory 
action). If the reschedule flag is 1, the program automatically schedules the 
action beginning at the designated start time, and automatically reschedules it 
from the start time to the end of the run in increments of delta t. Each time 
an external output is triggered for that set, either at regular time intervals 
or by the internal logic, the external output action is executed which saves 
the requested data in the QM-1 main store buffer. At the end of the batch, the 
entire memory buffer is written to disk file(s). Figure 13 shows a diagram of 
the external outputs action structure. 



Control Control 

Action £or eo set 1 Store Store 

Data Address 

— I Registers Registers 



External Output 

Control Buffer 



run 1- 

run 2 
run m 



run 1- 
run 2 


eo set 1 


eo set 2 


eo set n 


Note: eo » external output; assume n external output sets and m runs in batch 
External Output Control Store Action Data Structures 

External Outputs Action Structure 

Figure 13 
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4.4 Algorithms 


4.4.1 Initialization Algorithm 

In the netlist, the user must specify the initial output value for 
anywhere from one to all devices. The algorithm works as follows: For each 
device , a record is kept of all input lines and the values on those input 
lines, as well as any initial user-defined output value for the device. In 
addition, a separate list is kept of all devices for which all input lines to 
that device have defined values. This list is then processed one device at a 
time. For each device whose input lines are all defined, its output value is 
calculated. If the predefined output value, if any, does not agree with the 
calculated value, then the user is notified, and the calculated value is used. 
In the case of a flip-flop, if the preset line is active, the output is set to 
one, whereas if the clear line is active, the output is set to zero. If 
neither preset nor clear is active, the output is set to the user's predefined 
output value if any is present. Next, the fanout from this device is examined, 
and the input lines to all devices to which it fans out are set accordingly. 

As these input lines are being set, the destination device is examined to see 
if after this input line is set, whether all of its inputs are then defined. 

If not, the program proceeds to the next destination device. If so, the 
program calculates an output value consistent with the input values, and then 
this destination device is added to the list of defined devices. 

Simultaneously, a check is made to see whether the predefined value, if any, 
agrees with the calculated value. If not, the user is notified, but the output 
value is set to the calculated value. This procedure continues for each device 
on the "defined" list, and hopefully the "defined" list grows as the procedure 
continues. After the program has processed the last device on the "defined" 
list, the initialization procedure has been completed. If at this time, all 
devices have defined output values, the initialization is considered 
successful; however, if not all the devices are on the "defined" list, the user 
is notified. He may choose to proceed with the emulation, but it would be a 
better idea to correct the netlist and do the initialization again before 
attempting an emulation. 


4.4.2 Functional Emulation Algorithm 

The functional algorithm schedules actions, executes actions at the times for 
which they have been scheduled, and implements the faulting of gates and 
memories. One iteration of the functional algorithm proceeds as follows: 

Actions are scheduled as follows: 

If the master action control switch is not on, no actions are to be 
scheduled. If the master action control switch is on, then each action 
control record is examined in turn. For each bit in an action control 
record which is on, the appropriate action (whose address is found in the 
corresponding word in the action control buffer) is scheduled. 

Actions are then executed as follows: 

The first event in the event list is examined. If its time is less than 
or equal to the current time, then all the actions to which it is linked, 
are executed, and that event is removed from the event list. If the time 
of the first event is greater than the current time, no actions are 
executed (because events are linked in order by ascending time). 
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Faulting of gates is carried out: 

If there are any gates to be faulted or from which faults are to be lifted 
during this time period, the "faulter" gate is enqueued with connections 
to all gates which are to be faulted or from which faults are to be 
lifted. This enqueueing/dequeueing of the "faulter" gate insures that the 
fault will be inserted/lifted in the next time step. 


4.4.3 Gate-level Algorithm 

The gate-level algorithm examines only those devices whose output values 
changed during the previous period, and using this information, calculates 
which devices change output value during the current time period. Initially, 
there must be at least one device on the c stack. A device on the stack is one 
whose output has changed during the previous time period. One iteration 
consists of processing each device on the c stack and simultaneously building 
the cbar stack. 

Processing of one device from the c stack proceeds as follows: 

The device is removed from the top of the stack. It is then checked to 
see whether its output value has changed an even or odd number of times 
during the previous period. If the output value changed an even number of 
times, then this device need not be processed at all. If, however, it 
changed an odd number of times, then processing continues. Processing of 
a given source device from the stack consists of processing all internal 
connections from this device and then processing all external connections 
from this device. 

The Internal Connections are processed as follows: 

Each device into which this device feeds (destination device) is 
examined. The processing algorithm for the destination device depends 
on the type of internal connection: 

If Connection is to a gate or tri-state(but not the enable input): 

The count (see Section 4.4. 3.1) of the destination header is 
appropriately updated. Next the current count and the initial count 
(before the updating took place), are examined. If neither is zero, 
then no more processing of this destination device is necessary; 
however, if either one is zero, then this destination device must be 
processed further. First the internal value is complemented. Next 
a check is made to see whether the gate is enabled. If not, no 
further processing is needed. If the gate is enabled, processing 
proceeds: the internal value is copied to the external value. Next 

a check is made to see whether this destination device is already on 
the cbar stack (as a result of its output value having changed 
because of a different source device which was already processed 
from the c stack). If it is on the stack, then all that is done is 
to update its header item which indicates whether it has changed an 
even or odd number of times. If it is not already on the cbar 
stack, then it is enqueued on that stack. 

If Connection is to a flip-flop or to the enable line of a tri-state: 
The processing carried out depends on the type of connection. In 
the case of a flip-flop, first the particular input in the header is 
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complemented , whether it be P, C, T, L, J, K, or D (J and K). Hie 
rest of the processing is particular to the type of connection. 
Again, the destination device is examined to see whether or not it 
should be enqueued on the cbar stack. 

The External Connections are processed as follows: 

The new output value from the source device is copied into all bits in 
external registers into which this device feeds. It should be noted 
that any time the high order bit in the master action control register 
is turned on (it is in an external register and is turned on if any 
device feeding it goes high), then the next time the functional 
algorithm is executed, some action(s) will be scheduled. The particular 
actions scheduled will be those corresponding to the one bits in the 
action control register (s). 


Once this item from the c stack has been processed, the processing of the 
next source device from the c stack proceeds. This looping continues until the 
c stack is empty and the cbar stack represents the new stack. This consists of 
one iteration of the gate-level algorithm. 


4.4.3. 1 Description of Device "Count" 

For each regular gate and tri-state device, a count is maintained within 
the header record. The purpose of this count is to enable the program to know 
(without explicitly calculating the output value as a function of the input 
values) when the output value of a simple gate has changed. The "count" for 
each device is initialized as shown in Figure 14. 
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Type of Gate 

Initial Value 
of "count" 

AND 

N 0 -M 

NAND 

N 0 -M 

OR 

N 0 

NOR 

N 0 

NOT 

0 

XOR 

N 0 -n 

NXOR 

N 0 -n 


M = total number of input lines to this device 
N 0 ■ number of input lines that are high initially 
n = number of input lines high which result in high 
output ( XOR , NXOR only) 

"Count" Initialization 

Figure 14 


Each gate is restricted to not more than 31 (decimal) inputs. 

Once the emulation has begun, the count is maintained as follows: 

Each time an input line transitions from zero to one, the count is incremented 
by one. Each time an input line transitions from one to zero, the count is 
decremented by one. Any time the count transitions into or out of zero, the 
output value of the device is complemented . 
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5. User’s Guide 

5.1 Installation of Programs 


5.1.1 installation of Emulator on Vax (Using Vax/VMS): 

Note: This installation is necessary even if all production runs will be 

done on the QM-1, because the initialization and file transfers must be done 
from the Vax. 

Notation Used: 

user represents the name of the user's root directory (without the 

brackets). For example, if the user's root directory is (Smith], 
then in this document, user represents Smith. 

Underlined items are those which the user types. 


Installation Steps: 

A tape has been created using the vms Utility Backup. This tape has ID 
"bberaul" and Save Set Name "diagem.bck". This tape contains the following 
hierarchy of directories: 

[bb.dem] 


1. 

( bb . dem. emulator ] 

source programs and command files for 
compiling and linking emulator 

2. 

(bb.dem. run] 

command files for running emulator 

3. 

( bb . dem. transfers ] 


( bb.dem. transfers .qml vax ] 

programs and command files for 
transfers from QM-1 to Vax 


(bb.dem. transfers .vaxqml ] 

programs and command files for 
transfers from vax to QM-1 

4. 

[bb.dem. templates ] 

Templates for data files 

5. 

(bb.dem. targets] 



( bb.dem. targets . counter ] 

all data files for 3-bit counter 
circuit 


( bb.dem. targets . toy ] 

all data files for toy computer 
circuit 


[ bb.dem. targets . test ] 

all data files for RTI test circuit 


( Mb. dem. targets . comm ] 

all data files for RTI communicator 
interstage circuit 


In all cases it is necessary to restore 1. and 2. If one wishes to do 
transfers, one must restore 3. If one wishes to use templates, one must 
restore 4, and if one wishes to use sample target circuits, one must restore 
any or all of the subdirectories of 5. 
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Assume the tape has been physically mounted on msaO: 

Use the following commands to restore all directories and subdirectories 
from the tape : 

$Mount/foreign msaO: 

$Backup/verify msaO : diagem .bck/save/select- [ bb ♦ dem. . . ] 

[user, dem. .. ] (restore from tape) 

$set default [user. dem. emulator] 

$gcompandl ink emu (compile and link programs) 


Example of Installation: 

Assumptions: Name of user root directory is (Smith] 

$Backup/verify msaO :diaqem.bck/save/select=»[bb. dem. ♦ . ] 

[smith. dem. . . ] 

(Restore programs from tape) 

$set default [smith. dem. emulator] 

$gcompandlinkemu (Compile and link programs) 


To Make Modifications to Existing Programs 

To make changes to existing initialization Program: 

$set default [user .dem. emulator] 

Edit appropriate Fortran module(s) in [user .dem. emulator] 
Do Fortran compiles of appropriate module(s) 

$@initlink (links initialization programs) 


To add new module(s) to existing initialization Program: 

$set default [user. dem. emulator] 

Create new Fortran modules in [User. dem. emulator] and compile 
Add new module name(s) to ini t. opt file in [user .dem. emulator] 
$ ginitlink (links initialization programs) 


To make changes to existing emulation Program: 

$ set default [user .dem. emulator] 

Edit appropriate Fortran module(s) in [user .dem. emulator] 
Do Fortran compiles of appropriate module(s) 

$gemullink (links emulation programs) 
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TO acid new module(s) to existing emulation Program: 


$set default [ user .dem. emulator] 

Create new Fortran modules in [user, dem. emulator] and compile 
Add new module name(s) to emul.opt tile in [user . dem. emulator ) 
$gemullink (links emulation programs) 


5.1.2 Installation of Emulator on QM-1 

Note: This installation is not necessary if all production runs are to be 
done on the Vax. In order to proceed, one needs at the minimum a working 
knowledge of the Nova and Easy Operating Systems on the QM-1. 


Notation Used: 

Underlined characters are those which the user types into the QM-1 
Operating System. 

<CR> represents Carriage Return. 

<ESC> represents "escape" 

<Z> represents "control" key and Z key pressed simultaneously 


The Diagnostic Emulation System Tape was created in Airlab at Langley 
Research Center using the DISK-SAVE function of the EASY operating system. 
The tape contains users 6 and 8 in that order. User 6 contains the 
diagnostic emulation programs, and user 8 contains the Vax-to-QMl and the 
QMl-to-Vax transfer programs. Note that the tape files can be restored to 
users other than 6/8 by specifying the desired users in the USER- 
FORMAT, USER- command and in the DIRECTORY SEARCH command. 


5. 1.2.1 Restore Emulation System From Tape to Disk: 

Mount User Disk (it is assumed for this document that the disk is mounted 
on drive 0, but it could be mounted on any drive) 

Mount Emulation System Tape (it is assumed for this document that the tape 
is mounted on drive 0, but it could be mounted on any drive) 

Press Master Clear, Start 

???L DEASY 

SET DATE AND TIME 

J !DAT E,XX/XX/XX 


! !TIM E,XX/XX/XX 
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MDEADSTART 


I ! EASY-SPACE ,BS-26 , TPS- 347777 


! !<CR> 


! I RESTORE-DI SK , PASSWORD-HELP, MTUNIT-0,MTFILE-0 , DSKUNIT-0 
t 1 USER-FORMAT, USER-6 
MOUNT TAPE ON DESIRED UNIT 

HIT ANY KEY TO CONT. , ESCAPE THROUGH 'ESC' KEY 
(ANY KEY) 

SV-RES HEADER 
DATE-XX/XX/XX 
TIME-YY : YY : YY 
USER MODE 
ALL OF USER 6 

TO ACTIVATE HIT RETURN 
<CR> 

HIT RETURN TO UNLOAD 
<ESC> 

(user 6 has now been restored from tape to disk) 

! ! USER-FORMAT, USER-8 
MOUNT TAPE ON DESIRED UNIT 

HIT ANY KEY TO CONT., ESCAPE THROUGH 'ESC' KEY 
(ANY KEY) 

SV-RES HEADER 
DATE-XX/XX/XX 
TIME-YY : YY : YY 
USER MODE 
ALL OF USER 8 

TO ACTIVATE HIT RETURN 
<CR> 

HIT RETURN TO UNLOAD 

(user 8 has now been restored from tape to disk) 

<CR> 

<Z> 


5. 1.2. 2 Compile & Link Easy Programs: Vax<~>QM-1 Transfers 

1 IDIRectory, Search lst=06,2nd=,08 

•>EXEC BBEXl (compile Easy programs) 

! IBIND. (link Easy programs) 



! ! INCLUDE BBTEMPl 
! ! INCLUDE BBTENP2 
••INCLUDE BBTEMP3 
! ! INCLUDE EBTEMPj 
!! INCLUDE BBTEMP7 
I J INCLUDE BBTEMP9 
! ! INCLUDE BBTEMP12 
! I INCLUDE BBTEMP41 
! 'WRITE BBTEHP61 
! ! <Z> 

!!BIND 

! ! INCLUDE BBTEMP55 
I! INCLUDE BBTEHP61 
! ! INCLUDE BBTEMP56 
! I INCLUDE BBTEMP57 
S ! INCLUDE BBTEMP58 
1 1 WRITE BBVWCQMl 
! 1 <Z> 

! I BIND 

! ! INCLUDE BBTEMP9 
S ! INCLUDE BBTBiPT 
! ! INCLUDE ACWRTR:B 
1 1 INCLUDE BBTEWP54 
• ! INCLUDE BBTEMP49 
! ! INCLUDE BBTEHP46 
! ! INCLUDE BBTEHP47 
••WRITE BBTEMP31 
1 KZ> 

I! BIND 

• ! INCLUDE BBTEMP66 
••INCLUDE BBTEHP67 
! ! INCLUDE BBTEMPM 
! ! INCLUDE BBTEKP41 
l {INCLUDE BBSCR4 
••INCLUDE BBTEMP31 
! ! WRITE BBTP1P71 
1 !<Z> 

• 'BIND 

! '.INCLUDE BBWVWMN:B 
• ! INCLUDE BBMVSBPiB 
! ! WRITE BBTEMP72 
1 1<Z> 

1 1 BIND 

• ! INCLUDE BBTEHP71 
••INCLUDE BBTEHP72 
! 'WRITE BBMV 
! 1 <Z> 


5.1. 2.3 Generation of program to write External Outputs to Disk 

liSIMPLQ SM WXWDISKiS WXHDISKiB $ 


5.1. 2.4 Generation of Microcode Driver 
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PRESS Master Clear, Start 
???LDNOV 

iuser~6~ 

l EX /BBECOMPILE 


5. 1.2. 5 Generation of Nanocode Emulator 
PRESS Master Clear, Start 
???LDNOV 
! USER‘S 
!LD*NASPC 

l.S=2 INPT=/BBEMP1V1 : S BIN=/BBBNBIN 
!NP INPT-/BBEMP1V1 : S BIN-/BBEMP1V1 

!np inpt=/bbemp2v1 : s bin=»/bbemp2v! 

!NP I NPT-/BBEMP3V1 : S BIN-/BBEMP3V1 
!NP INPT=/MSNANCN:S BIN*/MSNANO:B 
!MAP INPT-/BBEMP1V1 BIN=W2 
•MAP INPT-/BBEMP2V1 BIN-W3 
•MAP INPT=/BBEMP3V1 BIN-W\3 
•MAP INPT*/MSNANO:B BIN-/MSNAHD:M 


- 39 - 


5.2 Data Preparation 


5.2.1 Suggested QM-1 Template 

In preparing to emulate a system, one of the preliminary steps for the 
user is to manually lay out the QM-1 memory to accomodate the various data 
structures. This step must be done whether or not the entire emulation will be 
done on the Vax or part on the Vax and part on the QM-1. The reason for this 
is that when the Vax emulator was written, it was assumed that the "production" 
runs would always be done on the QM-1 and that only "debugging" runs would be 
done on the Vax. Thus the Vax initializer always sets up the data as if it 
were to be run on the QM-1. 

The main store of the QM-1 must be used for the target memories, the fault 
buffer, the external input list, and the external output buffer. All other 
data structures, including the netlist and external registers, are stored in 
control store. A suggested layout for the QM-1 memories, which should 
accomodate most emulations, is shown in Figure 15 (note that control store 
locations 0 through 1777 cannot be used by the user. 


CONTROL STORE 

location contents 

(octal) 


TF 


1777 

2MF 


2377 

jm 


2717 

THU 

2722 

Tm 


reserved for nanocode implementation 


free space and events(3 words per event) 


memory actions ( reads, writes) 


stop action(3 words) 

Stop action(3+n words where n-no. of memories) 


3777 


Externals 
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4000 

4001 


time 


4427 

4430 

4431 


master action control register 
action control bits 
pointers to actions 


4474 

4475 

4476 


more action control bits 
pointers to actions 


4541 


4777 
W5 \ T 
5177 
52W~ 
5277 

5477 

5W 

5737 

~5TW~ 

7277 


external output address registers(l word each) 


external inputs address registers(l word each) 


external inputs data registers(size of each is 
determined by no. bits 
given in *eopts.dat) 


external outputs actions (8 words each) 


external inputs actions (each action is lO+n words 
where n is the no. of bits 
given in *eopts.dat) 


ISW0 


netlist in binary form 
(hardware description matrix) 
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location 

(octal) 


MAIN STORE 


contents 


7777 


target memories 


10000 

10777 


externals (if any) 


11000 


12777 


fault buffer 
(ihe total size is determined by the fault list) 
no. words code function 
2 


2 stop run: 

3 3 stick gate 0 

3 4 stick gate 1 

3 5 lift gate fault 

5 6 insert fault in ram op, t, mem id, word 

5 7 lift fault from rom op, t, mem id,word 


data used 
op,t 

op, t, gate no. 
op, t, gate no. 
op, t, gate no. 


id, bit id 
id,bit id 


external inputs list 

(there is one ei list for each ei set. 
the size of each list is n*(mfl) where 
n is the no. of times an external input is inserted 
m is the no. of 18-bit words required to hold 
the no. of specified bits for this set) 

(the external inputs list is stored automatically by the program 
at the next 100, word boundary following the fault buffer) 


external output buffer 

(there is one buffer for each eo set 
the size of each buffer is n*(m+l ) where 
n is the no. of times an external output is written 
m is the no. of 18-bits words required to hold 
the no. of specified bits for this set) 

(the external outputs buffer is stored automatically by the 
program at the next 100 8 word boundary following the 
external inputs list) 


QM-1 Memory Template 

Figure 15 
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5.2.2 Setup of Functional Memories 

In most cases, target memories will be implemented at a functional level. 
Outlined below are the steps the user must take to set up for this functional 
emulation. These memories may be any combination of ROMS and RAMS. There are 
two types of actions associated with memories, namely read memory and write 
memory. Each ROM should have at least one read associated with it, and each 
ram should have at least one read and one write action associated with it. In 
order to implement a given memory, it is the user's responsibility to do the 
following (see Section 5. 4.1.2): 

1. In the netlist, there must be a single device of any kind whose output 
line controls when the read/tor ite takes place. The appropriate action 
takes place only when this line transitions from low to high. The 
output of this device must feed the master bit in the master action 
control register, and it must also feed to a unique bit in a "control 
bit" word in the action control block. 

2. The address of the action to be performed when the control line goes 
high, together with a delta time to be added to the current time for 
scheduling, must be placed in the appropriate words of the action 
control block, in the memories files. 

3. For each read and write action, a separate data register(s) and an 
address register must be set up as externals in control store. The 
address register must be fed from the appropriate devices in the 
network for both reads and writes. The data register for a read has no 
explicit connections to it in the netlist. The identification numbers 
of the devices to which the memory data will be fed when the read is 
triggered must be designated within the read action. In the case of a 
write, the data register must have explicit connections from some 
devices in the netlist. For a RAM, the read and write actions must 
have different data registers. A given memory may have more than one 
read and/or write action associated with it. See A-36 and A-37 for 
read and write layouts. 

4. It is the user's choice as to whether the address in the 18-bit address 
register is to be right or left-justified. This choice is determined 
by the bit positions in the address register into which the appropriate 
devices feed. The value of item W in *iopts.dat depends on the user's 
choice. Item W is the value by which the address in the address 
register must be divided to right- justify it in the 18-bit word. For 
example, if the user chooses to let the address be right- justified in 
the address register, then W=l; if the address is left- justified, and 
is represented by 6 bits, then W=«2**12 or 4096. 

5. The read and write action data structures must be provided by the user 
in the *mems.dat file. 

6. The address of the action control block must be given in item D5, the 
address of the master action register must be given in item D7, and the 
number of memory control records must be given in item D6 of 
*iopts.dat. The number of memory control records is the number of 18- 
bit words needed to hold all control bits for the entire emulation. 
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7. The number of memories must be given in item V of *iopts.dat. 

8. The initial contents of the target memories must be given in *mems.dat. 
These memories are implemented in the main store of the QM-1, hence 
these entries will begin with "M" in column 1. 

The contents of each word of the target memory may use one or more QM-1 
18-bit words, depending on the number of bits in each target word. For 
a particular memory, let n represent the number of 18-bit words 
necessary to hold one target word. The user may decide whether the 
target word will be left- justified or right- justified over these n 
words. When the read action(s) for this memory are generated, it 
should be noted that word 9 of the action corresponds to bit 17 of the 
first of the n QM-l-words, word 10 corresponds to bit 16, etc.. Thus, 
if the memory contents are left-justified, word 9 contains the device 
identifier of the device into which the most significant bit of the 
data feeds, etc.; however, if the data is right- justified in the 
memory, an appropriate amount of zeros would appear in words 9 ff. to 
correspond to the leftmost data bits that are not used. In addition, 
item D in word 1 of the read/Write action is affected by whether the 
data is right or left justif ied( see the description of the read/Write 
action data structure). 

9. If the number of memories is greater than zero, the relocation 
constant(s) for the memories must be given in items Vl-Vh of 

* iopts.dat. The relocation constant is the amount by which the 
contents of the memory will be offset from absolute location 0 in the 
QM-1 main store, when the user lays out the QM-1 memory, he must 
determine at which QM-1 absolute location (for example, x) that each 
ROM or RAM will begin. Then he has a choice of two ways in which he 
can present the initial data for the target memories, in the memories 
file. Using the first method, he will specify a relocation constant of 
0, and in the memories file, he will specify that the first word of 
memory begins in location x, etc. Using this method, if the actual 
memory begins at target location 0, he must manually add x to every 
location for this memory that he specifies in the memories file; 
however, if he wishes the program to do the relocation, then he would 
use the second method. In this case he decides into which absolute 
QM-1 location (say x) that the memory will begin; he gives x as the 
relocation constant in items Vl-Vh of *iopts.dat, and in the memories 
file, he gives the contents beginning in location 0, and the program 
automatically adds x to each location. 


10. The data registers associated with read actions must be initialized in 
the *mems.dat file to values consistent with the output values of the 
devices to which the data register feeds. 
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5.2.3 Setup of Faults 

If one wishes to fault gates, it is necessary to include two extra dummy 
gates at the end of each netlist. A template for these is shown in Figure 16. 
It is also necessary to enter the name of the dummy faulting device (in this 
case ZZZFAULTER) in *iopts.dat, item E. See Section 5. 4. 1.2. 3. 2. The names of 
the two devices is arbitrary, but they must be the last devices in the netlist, 
and the names in the netlist must be in ascending order. A file containing 
this template is on directory [ bb.dem. templates ] . (see Section 5.1.1) 

! template for the two standard faulting devices 

J allows for 30 gate faults per time step. (can be increased) 


I 

• 

These two 

devices 

should be included . 

at the end of 

the netlist 

> ZZZFAULTER 

1 

CLASS- 

1 

TYPE- 1 VALUE- 

0 NICON- 

30 

NECON- 

1 

ZZZFAULTER 

10 

ZNAME- 


ZZZZDUMMY 

REVER- 

0 

CONNT- 

8 

ZZZFAULTER 

10 

ZNAME- 


ZZZZDUMMY 

REVER- 

0 

CONNT- 

8 

ZZZFAULTER 

10 

ZNAME- 


ZZZZDUMMY 

REVER- 

0 

CONNT- 

8 

ZZZFAULTER 

10 

ZNAME- 


ZZZZDUMMY 

REVER- 

0 

CONNT- 

8 

ZZZFAULTER 

10 

ZNAME- 


ZZZZDUMMY 

REVER- 

0 

CONNT- 

8 

ZZZFAULTER 
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Figure 16 
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5.2.4 Setup of External Inputs 


The user may create zero or more sets of external inputs for a given 
emulation batch. See Section 4.3.10.4 for a description of external inputs. 

It should be noted that the same external input files will be reused for each 
run in the batch. It is the user's responsibility to: 

1. Set items in *iopts.dat (see Section 5. 4. 1.2. 3): 

Set items X, Z, and AA to appropriate values. 

2. Set items in *eopts.dat (see Section 5. 4. 2. 2.2): 

Set item AA, which is the total number of external input files. 

Set items AAl , AA2 , and AA3 for each external input set. If item 
AA is zero, then items AAl, AA2, and AA3 are omitted. For each 
external input set, the user must create an External Input File. 

He can use any valid VMS file name for this file. Each external 
input file must have a unique name. This user-chosen name is 
specified in item AAl. Item AA2 specifies the number of bits to 
be supplied to the netlist from this set. Item AA3 lists the 
devices into which the bits feed. Note that the external input 
sets can be listed in any order. For each external input set, the 
devices must be listed in the order corresponding to the data 
bits, where the first device listed corresponds to the most 
significant data bit. 

3. Create External Input Files (see Section 5. 4. 2. 2. 4 for details): 

This step is omitted if item AA in *eopts.dat is zero. 


5.2.5 Setup for Producing External Outputs 

For a given batch, there may be zero or more external output files 
created. See Section 4.3.10.5 for a discussion of external outputs. An output 
file will be written for each external output set at the completion of each 
batch. 


If the user has specified that the number of external output sets is one or 
more, then it is his responsibility to do the following: 


1. In *iopts.dat, set items BB, and DD. 

2. In *eopts.dat, set item BB. 

3. In *eopts.dat, if BB is at least one, then set items BBl through BB5. 

4. In the netlist, create external register(s) to act as the external 
output data registers. The appropriate logic devices must feed into 
these registers. 

5. For any external output set for which automatic rescheduling is not 
used: 

In the netlist the appropriate device must be fed into the master 
action control bit and into a bit in some "control bits" word (see 
Sections 4.3.7 and 4.3.8). This device is the cue whose transition 
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from low to high will trigger the scheduling of the external output 
action. 

Set the address of the external outputs action(s) together with a 
delta time to be added to the current time for rescheduling in the 
appropriate words of the action control block in the memories file. 
It should be noted in determining the action addresses that the 
first external outputs action is stored at the address specified by 
the user in item BB of * iopts.dat, and that each external outputs 
action following the first is displaced from the previous one by 
10 (octal). 


5.3 Program Modifications 

5.3.1 Implementation of User-Defined Action 


Vax Version 

In order to implement a new action, one must do the following: 

1. Select an action code for use with this action. Each action must have 
a unique code. The codes 1 through 30 (decimal) are reserved for use 
by the emulator. The codes 50 through 55 are reserved for use by the 
University of Illinois. All other codes up to and including 127 
(decimal) may be used. 

2. Create the action data structure for this action according to the 
layout in A-35 and include it in *mems.dat. 

3. Write a new Fortran subroutine module to perform the action. See the 
already existing action modules, ACT2, ACT3, ACT6, ACT7, or ACT8 to 
see how this is done. Compile the new Fortran action subroutine. 
Modify the Fortran Module EXlACT (see A-9) to include a branch to the 
new action. Compile EXlACT. Modify the emulation link file emu. opt 
to include linking of the new subroutine. 

$ @emulink (see Section 5.1.1) 

4. Include an external connection from some device in the netlist to the 
master action control bit and another to some bit in the action 
control buffer, in order to trigger the action. A transition from low 
to high on the output line of this device will then trigger the 
action. 


QM -1 Version 

All of the above would be done. One would modify the corresponding 
microcoded routine "Exlact" and would create and assemble a new action 
routine written in the Multi language. 


5.3.2 Instructions for Increasing Array Sizes 

Vax Version 
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If one wishes to modify the array sizes for the components of the system, one 
should follow the steps below: 

1. Modify the dimension parameter(s) in the module "emuparam.for". 

Listed below are the parameters which specify the array sizes. The comment 
to the right of each parameter explains what that parameter represents. 


C EMUPARAM.FOR 

c dimension parameters 


parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 


(yndevi = 6000) 
(ynconn = 14000) 
(ynstac = 500) 
(yncomm = 100000) 
(ynmems = 30) 
(ynei = 20) 
(yneo = 20) 
(ynupc = 15) 
(ynstat = 500) 
(ynchid = 1000) 
(pcslow = 0) 

( pcsup = 20000 ) 
(pmslow = 0) 
(pansup = 120000) 
(plslow = 0) 
(plsup = 31) 


! maximum number of devices 
! maximum number of internal connections 
{maximum no. items on stack at one time 
{maximum no. bytes for device comments 
{maximum no. target memories 
{maximum no. external input sets 
{maximum no. external output sets 
{maximum no. user print choices 
{maximum no. state information devices 
{max no. devices to change at one time 
{control store low address 
{control store high address 
{main store low address 
{main store high address 
{local store low address 
{local store high address 


2. Recompile and link all programs (initialization programs and emulation 
programs) as described in Section 5.1.1. 


5.4 Running the System 

It is assumed for the purposes of describing these files that the user is 
familiar with Fortran Formats. All of the formats listed here are in the 
Fortran language. 

For all initialization and emulation runs executed on the Vax, all file 
names must be valid vms file names. For a particular target hardware, all input 
and output files should be on the same subdirectory and must begin with the same 
user-defined prefix. The suffixes are predetermined and listed in A-7 and A-8. 
For the purposes of this document, the prefix is always denoted with For 

example, assume the user specifies "counter" as his prefix. Then, in this 
document, *mems.dat would represent "countermems.dat". 


5.4.1 Initialization of Target Hardware on Vax 

5. 4. 1.1 General 


Before a given network can be emulated, it must be initialized. The 
initialization process is one in which the inputs are a description of the 
netlist in DENF format, the initial contents of the target memories, the 
initialization run-time options, and the device descriptions to appear on the 
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emulation stack outputs; the principle output is a complete description of the 
netlist with initial output values defined, and a complete representation of 
the initial memories, both in the binary form required by the emulator. 

Four input files are required for running the initialization program. Two 
output files are always produced, and another four output files are sometimes 
produced, depending upon the options the user has requested in *iopts.dat. 



Input Files 


Required Files 

*net.dat 

The target network description(netlist)in DENF 
format. See Section 5. 4. 1.2.1. 

*mems.dat 

The initial values to be resident in the host memory 
before the emulation begins. See Section 5. 4. 1.2. 2. 

*iopts.dat 

The run-time initialization parameters. See Section 
5. 4. 1.2. 3. 

*comm.dat 

The comments or descriptions to appear alongside 
device names when they appear on the stack output. 
See Section 5. 4. 1.2. 4. 


Output Files 


Mandatory Output Files 

*sav.dat 

Initialized System State File: Binary netlist and 
memories to be used as inputs to the Vax emulator. 

* iout.dat 

Text output which varies according to the options 
that the user has requested in * iopts.dat. 


Optional Output Files 

*mat.dat 

Netlist in a form to be used by the QM-1 for 
emulation. This file is only produced if item 0 is 
turned on in * iopts.dat. 

*extrn.dat 

Initial contents of control store external registers 
in a form to be used by the QM-1 for emulation. Uiis 
file is only produced if item 0 is turned on in 
*iopts.dat. 

*alph.dat 

A list in alphanumeric order by device name of all 
the devices in the netlist. Included with each 
device is the device name, device index number, 
device type, device class, and initial output value 
of the device, in the format 

(1X,A20,1X,I4,1X,2A10,1X,I1). This file is only 
produced if item R is turned on in * iopts.dat. 
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*nam.dat A list in alphanumeric order by device name of all 

the devices in the netlist. Included in each record 
is the device number in decimal followed by the 
device number in octal followed by the device name in 
the format (1X,I4,1X,06,1X,A20) . This file is 
produced to aid the user in creating a meaningful 
*comm.dat. 

Following is a detailed description of each file: 


5. 4. 1.2 Input Files 


5.4.1. 2.1 Netlist File 

The network description completely defines the target network of gate- 
level logic and the interconnections among the devices, all in the DENF format. 
Normally, this file would be generated from some preprocessor or translator. 
Each device and its fanout is described by a group of records, referred to as 
the "device definition". A device is defined as a regular gate (AND, NAND,OR, 
NOR, NOT, XOR, NXOR), a tri-state device or a flip-flop. Each record contains 
the name of the device being defined. Hie device definitions must be in 
asce nding order by device name, according to the ascii collating sequence. 
Within each device definition, the records must be~ in the order as specified 
below. The group of records necessary to specify a particular device 
definition varies according the device type. The maximum number of devices at 
present is 6000. The maximum number of internal connections is 14000. The 
maximum number of external connections is 6000. These numbers can be increased 
should it become necessary by changing dimensions in Fortran programs (see 
Section 5.3.2). There are four different types of Device Definition 
corresponding to: 

1. regular gate other than XOR or NXOR 

<device description 
< internal connections> 

<external connections> 


<device description 
<xor specification 
<internal connections> 
<external connections> 


<device description 
<tri-state specification 
Cinternal connections> 
<external connections> 

<device description 
<flip-flop specification 1> 
<flip-flop specification 2> 
< internal connections> 
<external connections> 


record 1: 

record 2 and following: 


2. XOR or NXOR gate 
record 1: 
record 2: 

record 3 and following: 


3. tri-state device 
record 1: 
record 2: 

record 3 and following: 

4. flip-flop 
record 1 
record 2: 
record 3: 
record 4 and following: 
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where: 

Cinternal connections> :» one or more Cinternal connection 
<external connections> zero or more <external connection 


Record Types: 

<device description format: (Ix,a20,i3,8x,i3,4(7x,i3) ) 

contents : NAME , SEQUEN , CLASS , TYPE , VALUE , NI CON , NECON 

<xor specification format : (1X,A20,I3,8X,I3) 
contents: NAME, SEQUEN, XORNN 

<tri-state specification fonnat : (1X,A20,I3,8X,I3) 
contents: NAME, SEQUEN, VDIS 

<f lip-flop specification 1> format : (1X,A20,I3,8X,03) 
contents: NAME, SEQUEN, FFVALUE 

<flip-flop specification 2> fonnat : (1X,A20,I3,8X,I3,7X,I3) 
contents: NAME, SEQUEN, R,U 

< internal connection format : (Ix,a20,i3,12x,a20,6x,i3,7x,i3) 

contents: NAME, SEQUEN, ZNAME,REVER,CONNT 

<external connection format : (1X,A20,I3,1X,4(7X,I3) ) 
contents: NAME, SEQUEN, CSMSF, REGNO, BITNO,REVER 


The symbols used for the "contents" above are as follows: 

NAME Device Name : the unique device name. The name must be at least one 
but not more than 20 printable ascii characters. While the name may 
contain any valid ascii printable characters, it must be remembered 
that in the netlist, these names must be in ascending order 
according to the ascii collating sequence. It Should also be noted 
that the two dummy devices used for faulting must be the last two 
devices in the netlist, and so must be named appropriately. Also 
note that upper case and/or lower case letters may be used in the 
name, but at any other point in an input file in which the name 
appears, the case must match, character by character, the case used 
in the netlist name. 

SEQUEN Sequence Number - this number is not used by the emulator. It is 

included in order to keep the records for one device in order during 
any sort by device name. For purposes of the emulator, it may be 
left blank. 

CLASS Device Class 
l=Gate 
2=Fl ip-flop 
3=Tri-state 

TYPE Gate Type 
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O=flip-flop 

1=AND 

2=NAND 

3=0R 

4=N0R 

5=N0T 

6=X0R 

7=NX0R 

VALUE Initial value on output line : 

User-initialization (item B in Init. Options File = 0) : 

Value must be 0 or 1 

Program will use the user-assigned value if there is no 
inconsistency. If there is an inconsistency, the user will be 
notified, and the calculated value will prevail. 
Program-initialization (item B in Init. Options File -1): 

Value must be 9 

Program will attempt to calculate the value. If it cannot, it 
will notify the user.) 

NICON Number of internal connections (This number represents the number of 
devices in the network to which the output of this device fans out). 
This number must be greater than zero. 

NECON Number of external connections (This number represents the number of 
"external" or "pseudo" connections to which the output of this 
device goes. These connections are not part of the internal 
network, but are used to hold output values of devices for the 
functional emulation.) This number can be zero or greater. 

For XQR and NXOR gates only: 

XORNN The exact number of input lines which must be high in order for the 
output line to be high. If the number of high input lines is less 
than or greater than this number, the output line will be low. 


For Flip-Flops Only: 

FFVAL Initial Flip-flop values (PCTLJK) 

This is an octal value which represents the initial value for bit 

positions 0-5 of the flip-flop header word. Bit 5 is the value on the 

P connection, bit 4 on the C connection, etc. 

See A-25, Device header Layout (Flip-Flop). 

For the purposes of initialization: 

P and C: the default is negative logic, i.e., the value of 1 is 

benign, and 0 is active on the preset and clear lines. This 
can be overridden at the time of initialization with a flag 
in the options file. 

T: the default is negative edge-triggered. This can be 

overridden at the time of initialization by using a 
connection type of -3 rather than 3. 

Note: During initialization, any value initialized by the user may 

be overridden if the program discovers an inconsistency. 
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R (Used for RS flip-flops) 

Indeterminate Flag 1. See A-28 and A-29, Device Connector to Flip- 
Flop, word 1, bit 9. Also see Migneault(2] . The initial value should 
be 0 if this feature is not to be used. 

U (Used for RS flip-flops) Indeterminate Flag 2. See A-28 and A-29, 
Device Connector to Flip-Flop, word 1, bit 8. Also see Migneault[2] . 
The initial value should be 0 if this feature is not to be used. 


For Tri-States only; 

VDIS The value the output line of the tri-state is to assume when it is 
disabled. This value may be 0 or 1. 


For Each internal Connection: 

ZNAME Name of the destination device, i.e., the name of a device to which 
this device fans out. 

REVER Reversal flag (reversal meaning same as inversion) 

0*no reversal entering the destination device 
l=>reversal entering the destination device 

CONNT Connection type 

0 = connection to a gate, or connection to a tri-state but not the 
enable line of the tri-state. 

1*P connection to flip flop 
2=C connection to flip flop 

3=»T connection to flip flop (downward edge-triggered) 

-3=T connection to flip flop (upward edge-triggered) 

4=L connection to flip flop 
5=J connection to flip flop 
6=K connection to flip flop 
7=D X connection to flip flop 
8=Enable line to tri-state 

1 "D" connection is one in which the K input is always the complement of 
the J input. 


For each External Connection: 

CSMSF Control Store/Main Store 

0=Control Store, l=Main Store 
REGNO Register Number 

The number of the external register. These are numbered beginning with 
Register 1. The number is decimal. 

BI1N0 Bit Number 

The number of the bit within the register. These are numbered from 0 to 
17. The least significant bit is numbered 0, and the most significant 
bit is 17. This number is decimal. 
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REVER Reversal flag (or inversion flag) 

0=no reversal entering the external register 
l=reversal entering the external register 


See Appendix C for a sample of a network description file. 


5. 4. 1.2. 2 Memories File 


Purpose 

The memories file specifies the values which are to be resident in the 
control store and the main store of the QM-1 at the beginning of the emulation, 
but which are not generated by the initialization program and must therefore be 
supplied by the user. For most emulations, these initial memory values are: 

In control store : 
memory read and/or write actions 
user-generated actions 
action control block 
initial memory data register contents 

In main store : 

actual contents of target memories 


Format 

The memories file may contain seven different record types. They are as 

follows: 

Type 1: column 1 contains "!" 

meaning: Remainder of record contains comments which are not used 

by emulator 

Type 2: columns 1-3 contain "ROM" (must be upper case) 

meaning: Remainder of this record is blank. Records following this 

record are of type 6 or 7, and they represent the contents of a 
target ROM. 

Type 3: columns 1-3 contain "RAM" (must be upper case) 

meaning: Remainder of this record is blank. Records following this 

record are of type 6 or 7, and they represent the contents of a 
target RAM. 

type 4: column 1 contains "C" or "c" 

meaning: The remainder of the record contains octal values separated 
by commas. Each octal value can occupy up to six columns and can 
have leading blanks. Hie first octal value represents the beginning 
control store location into which the remaining values will be 
consecutively placed. 

type 5: column 1 contains "D" or "d" 
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meaning: the remainder of the record contains octal values separated 
by commas. Each octal value can occupy up to six columns and can 
have leading blanks. The first octal value represents the beginning 
control store location into which the remaining values will be 
consecutively placed. The only difference between type 5 and type 4 
is that for type 5 the values to be placed into control store 
represent device index numbers. This type need only be used when 
preparing data for QM-1 emulation runs. 

type 6 : column 1 contains "M" or "m" 

meaning: the remainder of the record contains octal values separated 
by commas. Each octal value can occupy up to six columns and can 
have leading blanks. The first octal value represents the beginning 
main store location into which the remaining values will be 
consecutively placed. 

type 7: column 1 is blank 

meaning: the remainder of the record contains octal values separated 
by commas. Each octal value can occupy up to six columns and can 
have leading blanks. The first octal value in this case is not a 
location but the value to be placed into the next consecutive 
location after the last location of the previous record. The 
remaining values will be consecutively placed. 


Note regarding the order of the records in the memories file: 

All records describing the contents of ROMS and/or RAMS should be at the 
end of the memories file. All the records for one ROM or RAM must be 
contiguous. Obviously, all records of type 7 are order-dependent, since the 
location comes from the previous record. All other records besides those just 
mentioned are independent of order. 

Note regarding the relocation of ROMS and RAMS: 

Immediately preceding the first record for each target memory, a record 
must be inserted which consists of the word "RAM" or "ROM" in columns 1-3. It 
is used to identify the beginning of each new target memory for purposes of 
relocating it in the QM-1 memory and for identifying the memory identification 
for memory fault insertions. 

The user may, if he desires, request that the initializer relocate one or 
more ROMS and/or RAMS in the QM-1 memory. If he chooses to do this, he 
supplies the relocation constant to the program, and this relocation constant 
is automatically added to the location in the record, (see Section 5. 4. 1.2. 3, 
items VI. . .Vn) . 


Note regarding in-record comments: 

For any type listed above, if "l" appears in any column, then all columns 
after the "!" will be treated as comments. 
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5.4. 1.2. 2.1 Sample Memories File 


Following are examples of records within a memories file, *mems.dat.t 


Memories File 

This file contains all values to be placed 
during initialization into the ($1-1 
memory, both control store and main store. 

action #6, operations action 
C002725, 030000 ! code-6 


<- 

<- 


C002726, 000000 
C002727, 000000 
C002730, 002400 
C002731, 002440 
C002732, 002532 
C002733, 002600 
C002405,4406 
C002406,0,37 
13,35,4763 


ptr to next action 
reschedule time 
action address table-bank 1 
memory bank 2 
memory bank 3 
memory bank 4 

ICS location of data register 
I valid addresses for this memory 

<— 


COMMENTS (type 1) 
(not used by 
emulator) 


CONTROL 

STORE (type 4) 
CONTENTS 
(see note 1) 


(type 7) 


i 

! MEMORY #1, ROMS. 32.1, SEQUENCE CONTROL ROM 

ROM (type 2) (see note 2) 

M 005000 , 306, 307, 310, 311, 264, 264, 264, 264, 266, 312 <-, MAIN STORE CONTENTS ( type 6) 


M005020, 153, 154, 155, 156, 0,0, 0,0, 264, 265, 266 

I 
# 

I 

ROM 


<— 1 (see note 3) 

MEMORY #2, ROM8. 512.1, MICROCODE START ADDRESS ROM 


M 

0 , 

41, 

16, 

45, 

14, 

27, 

17, 

43, 

15 

M 

10 , 

50, 

40, 

44, 

34, 

51, 

46, 

42, 

35 

M 

20, 

262, 

272, 

276, 

102, 

264, 

273, 

277, 

103 


MEMORY #3, Raml6. 64.1 


RAM 


(type 3) (see note 4) 


M 0000, 

110001, 

440, 




< — | 


0400, 

1401, 

4001, 

1401, 

4002, 

1401, 

4003 

MAIN STORE 

0406, 

1401, 

4004, 

1401, 

4005, 

1401, 

4006 

C0NTBITS (types 

0420, 

1401, 

4011, 

1401, 

4012, 

1401, 

4013 

(see note 5) 

0432, 

1401, 

4016, 

177400, 

11000, 

77416, 

41017 < — 1 



Note 1: The first record causes 30000 8 to be placed into control store 

location 2725, . The second record causes 0 to be placed in control 
store location 2726., etc.. The ninth record places 0 into location 
2406 8 and 37 8 into location 2407 8 . The tenth record places 13, into 
location 2410, , 35, into location 2411. and 4763, into location 
2412, . Note that all of the text to the right of the "l" is merely 
comments . 

Note 2: The records that follow (until the next type 2 or type 3 record) 

contain the contents for the next target RC$1. 
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Note 3: These two records contain contents for a target ROM. The first 

record places the value 306 8 into main store location 5000 e , 307 e 
into location 5001,..., and as the last value for this record, 
places 312 8 into location 5011 8 . The second record causes 153. to 
be placed into main store location 5020., 154 8 into location 5021 8 , 
etc..., and finally 266 e into location 5032 8 . 

Note 4: The records that follow (until the next type 2 or type 3 record) 

contain the contents for the next target RAM. 

Note 5: These records contain contents for a target RAM. The first record 

places the value 110001 8 into main store location 0, and the value 
440 8 into location 1. The second record places the value 400 8 into 
location 2, 1401 8 into location 3,..., and finally 4003„ into 
location 10 8 , etc . . 


5. 4. 1.2. 3 Initialization Run-Time Options File 


The initialization options file *iopts.dat is an input file which contains 
parameters and user selections for the initialization run. The initialization 
options file is usually prepared manually with an editor. Listed below is a 
sample initialization options file. It can be used as a template for the 
user's preparation of his own file. Following the sample is a description of 
each of the records in an initialization options file. In order to facilitate 
the discussion, the individual records in the sample have been labeled on the 
far right with capital letters. Some of the items in this file are no longer 
used or are used only for debugging purposes. For that reason, only the items 
currently used that are relevant to the general user are so labeled. These 
capital letters are merely for documentation purposes. The general user need 
only be concerned with the labeled items. For all other items, they can be 
left at the values in the sample, but they must be present in the file in the 
order indicated. Items I through S control whether various option outputs will 
be produced. In each case, unless otherwise noted, the particular output will 
be produced as part of the *iout.dat file. If this is not the case, the name 
of the file produced is noted in the item description. 


5.4.1. 2.3.1 Sample Initialization Run-Time Options File 

Following is a sample of an Initialization Options file, *iopts.dat. The 
label for each record is a capital letter appearing to the far right of the 
record. It is for documentation purposes only, and does not actually appear in 
the record. 

The output options 1-50 (items I through S) are switches which control 
which outputs are produced. These options have no effect whatsoever on the 
initialization but are merely for the user's benefit if he wishes to see the 
initialization process in more detail (especially when the network has 
initialization problems), in each case, a 1 means the option is turned on and 
the corresponding output will be produced, while 0 means it will not. unless 
otherwise noted, the particular output will be produced as part of the 
*iout.dat file. If this is not the case, the name of the file produced is 
noted. The records not labeled with a capital letter are not used (i.e., the 
values are "don't care", but must still be present). 
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Note: In each record, text following the "l" is comments 

Abbreviations : 

In what follows, the abbreviation ei is used for 
external inputs, and the abbreviation eo is used for 
external outputs. Hie abbreviation cs is used for control store, 
and ms is used for main store. An asterisk (*) preceeding 
the name of a file represents the user-supplied prefix. 


Sample *iopts.dat File 


Any Title 

! Title for hardware being emulated 

A 

1 

! initialization flag 0-user, 1-computer 

B 

0 

! user val for no-input devices 

C 

1 

! preset-clear convention flag 0:l«benign 1: 1-active 

D 

020000 

! cs address for netlist 

01 

004000 

1 cs address for external registers 

D2 

000000 

I ms address for external registers 

D3 

004001 

! cs address for time 

D4 

004430 

! cs address of action control block 

D5 

000001 

I number of "control bit" words 

06 

004427 

! cs address of master action control register 

D7 

002720 

! cs address of stop action 

D8 

002000 

! cs address of free space list 

D9 

50 

! number of free space records 

D10 

003760 

! main store address of fault block 

Dll 

002725 

i cs address of operations action data structure 

Dl2 

ZZZFALJLTER 

l name of faulting device 

E 

004400,004407 

l cs lo,hi address for dump 

F 

000000,000000 

! ms " " " 

G 

000000,000010 

» Is " " " 

H 

1 

!*1 initial device headers **first output option** 

I 

1 

! 2 not used 


0 

! 3 not used 


1 

! 4 not used 


1 

! 5 not used 


1 

i 6 not used 


1 

! 7 not used 


1 

!*8 control store memory dump 

K 

0 

1*9 main store memory dump 

L 

0 

1*10 local store memory dump 

M 

1 

1*11 not used 


1 

! 12 not used 


0 

! 13 not used 


1 

1 14 netlist in QM-1 format 

0 

0 

! 15 not used 


1 

i *16 connections list 

P 

0 

! 17 not used 


0 

! 18 not used 


0 

! 19 not used 


1 

1*20 devices with undefined output values 

Q 

1 

1 21 devices with defined output values 

QQ 

0 

I 22 not used 


1 

! 23 not used 
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1 

1 

• 

24 memory dumps at stop time 

NN 

0 

1 

♦ 

25 alphabetized list of devices 

R 

0 

1 

• 

26 not used 


0 

1 

• 

27 device name list 

S 

0 

1 

• 

28 not used 


0 

1 

• 

29 not used 


0 

1 

• 

30 not used 


1 

1 

• 

31 not used 


1 

1 

32 not used 


1 

I 

• 

31 not used 


1 

1 

• 

32 not used 


1 

1 

• 

33 not used 


1 

1 

• 

34 not used 


0 

1 

• 

35 not used 


0 

1 

• 

36 not used 


0 

1 

• 

37 not used 


1 

1 

• 

38 not used 


0 

1 

• 

39 not used 


0 

1 

• 

40 not used 


0 

1 

• 

41 not used 


0 

1 

• 

42 not used 


0 

rp 

1 

• 

43 cs initialized external registers in QM-1 format 


1 

0 

1 

• 

44 not used 


0 

I 

45 not used 


0 

1 

• 

46 not used 


0 

! 

47 not used 


0 

i 

9 

48 not used 


0 

1 

• 

49 not used 


0 

1 

• 

50 not used 


1,1,1 

2 

XI 


Inot used 
Inot used 
! stack items 

U 

***** 

***** 

***** 

***** 

3 

1 

i 

i 

♦ 

I 

9 

1 

9 

no. of target memories 

V 

001000 

1 

• 

relocation constant for memory 1 

VI 

005500 

1 

• 

relocation constant for memory 2 

V2 

006300 

1 

• 

relocation constant for memory n 

vn 

1 

1 

divisor to right justify target address 

W 

005000 

1 

address in cs for first ei action 

X 

000200 

1 

9 

not used 


004500 

1 

• 

address in cs for first ei address reg 

z 

004540 

1 

• 

address in cs for first ei data reg 

AA 

000160 

1 

• 

address in cs for first eo action beg of eo 

BB 

000200 

1 

• 

not used 


000150 

1 

• 

address in cs for first eo address reg-end eo 

DD 

015000 

i 

highest loc in cs to go to save file 

EE 

020000 

! 

highest loc in ms to go to save file 

FF 

000031 

1 

highest loc in Is to go to save file 

GG 
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5.4.1. 2.3.2 Record Descriptions for Init. Run-Time Options File 


Formats : 

In each item, the Fortran format follows in parentheses after the 
name of the item. 

Descriptions: 

A Title (10a4) : Any title which describes the target hardware. 

Ihis title will appear at the beginning of the initialization output 
file *iout.dat and at the beginning of the emulation output file 
*eout.dat, preceded by "TARGET MACHINE:". 

B Initialization Flag (II) 

If set to 0, user must supply output values for all devices in *net.dat. 

If set to 1, user will supply at least one device output value, but may 

supply more. Program will attempt to calculate any values not supplied. 

C User-supplied value for devices with no inputs (II) 

For each device which does not have any inputs, and no predefined value, 
this value will be used as its output value. 

D Preset-clear convention flag (II) 

If set to 0, then a value of 1 on either the P or C input to any flip- 

flop will be treated as benign, i.e., will not cause the output value to 

be set or cleared respectively. 

If set to 1, then a value of 1 on either the P or C input to any flip- 
flop will be treated as active, i.e., will cause the output value to be 
set or cleared respectively. 

Dl Control Store Address for Netlist (06) 

Hie starting address in control store for the binary netlist (06) 

D2 Control Store Address for External Registers (06) 

The starting address in control store for external registers, (the first 
register is referred to as register number 1) 

D3 Main Store Address for External Registers (06) 

The starting address in main store for external registers. 

(not generally used) 

D4 Control Store Address for Time (06) 

The address of some cs external at which the current time will be stored 
at each clock cycle, to be available for output if so desired. It can 
be dumped in any format by using items Zl and Z2 in the *eopts file. 

D5 Control Store Address of Action Control Block (06) 

The starting address in control store of the action control block. 

D6 Number of "Control Bit" Words in Action Control Block (*) 

The number of QM-1 18-bit words needed to hold all the control bits for 
the emulation. 

D7 Control Store Address of Master Action Control Register (06) 
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The control store address of the master action control register which 
contains the master bit which goes high any time at least one control 
line goes high. 

D8 Control Store Address of Stop Action (06) 

The starting address of the stop action in control store. 

D9 Control Store Address of Free Space List (06) 

The starting address in control store of the free space and 
event lists. 

DIO Number of free space records (*) 

The maximum number of free space records to provide space for. Each 
record takes three QM-1 words. 

Dll Address of fault block in main store (06) 

The starting address in main store where the fault list will reside. 

D12 Control Store Address of op action data structure (06) 

The control store address of the op action ( action 6 ) . 

E Name of Faulter Device (A20) 

The name of the device to be used for faulting gates. 

F QM-1 Control Store Dump Locations (06,lX,06) 

The starting address(in octal) of the block of control store to be 
dumped, followed by the ending address (in octal) of the block of control 
store to be dumped. The dump takes place after initialization only if 
print option 8(item K) is on. 

G QM-1 Main Store Dump Locations (06, IX, 06) 

Same as F, but for Main Store and print option 9 (item L). 

H QM-1 Local Store Dump Locations (06, lx, 06) 

Same as G, but for Local Store and print option 10(item M). 

I Initial Device Headers (II) 

If this option is turned on, the initialization output will 
contain a list (in octal) of the initial header word for each 
device in the netlist along with its QM-1 control store address. 

K Control Store Dump Option (II) 

If this option is on, the control store range specified in item F 
will be dumped after initialization. 

L Main Store Dump Option (II) 

If this option is on, the main store range specified in item F 
will be dumped after initialization. 

M Local Store Dump Option (II) 

If this option is on, the local store range specified in item F 
will be dumped after initialization. 

0 Netlist in QM-1 format (II) 
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If this option is on, a file (*mat.dat) will be produced which can be 
sent to the QM-1 for emulation on that machine. This file contains the 
entire netlist in a matrix form to be used by the QM-1. This option 
would only be on if one is intending to do the emulation runs on the QM- 
1 . 


P Connections List (II) 

A complete list of the network, showing for each device, all the devices 
which feed into it, the device types, and the initialized output value 
for each device. 

Q Devices with undefined output values (II) 

A list of all devices for which the program was not able to determine 
the output value. The user should analyze the netlist, correct the 
problem, and rerun the initialization. This should usually be turned on 
to see if there are any problems in the netlist description. 

QQ Devices with Defined Output Values (11) 

A list of all devices for which the program was able to determine the 
output value. 

R Alphabetic List of Devices (II) 

If this option is on, a file(*alph.dat) will be produced. This file 
contains the name, number, type, class, and initial output value of each 
device in the netlist, in alphanumeric order by name. 

S Device Name List (11) 

If this option is on, a file(*nam.dat) will be produced. This file is 
to be used as a template for use with some editor to manually produce 
the file *comm.dat. It would normally only be necessary to produce this 
file once, and then to edit it as changes are made to the netlist. It 
is not necessary to produce this file at all if comments are not desired 
in the stack dumps produced during the emulation runs. See Section 
5 . 4 . 1 . 2 . 4 . 

T Control Store Initialized External Registers in QM-1 Format (II) 

If this option is on, a file (*extrn.dat) will be produced which 
contains the control store initialized external registers in the format 
necessary to be sent to the QM-1 for emulation on that machine. This 
option would only be on if one is intending to do the emulation runs on 
the QM-1. 

U Stack Item(s) (A20) 

The names of all devices on the initial stack. There will be one record 
for each device on the initial stack. There must be at least one item 
in this list. The items can be in any order. The same initial stack 
will be used for each run in the batch. 

V Number of target memories (*) 

If this value is 0, then items Vl through Vh are not to be included. If 
this value is greater than zero, say n, then Vl through Vh must be 
included. 

Vl..Vn Memory Relocation Constants for memories 1 through n (06) 
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The number of locations by which each target memory will be relocated in 
the QM-1. Each target memory is stored in the main store of the QM-1, 
and thus must have some relocation constant to map it into the memory of 
the QM-1. The contents of each target memory as specified in *mems.dat 
may either be manually relocated in the QM-l's memory by the user, or 
may be relocated by the program. If the user does the relocation, enter 
a 000000 here. If the program is to do the relocation, enter the 
relocation constant here. If the user does the relocation, then all 
memory addresses for main store in the *mems.dat file are absolute QM-1 
addresses, i.e., the actual target address plus the QM-1 relocation 
constant. If the program is to do the relocation, then each main store 
address in the *mems.dat file is the target memory address. Regardless 
of whether or not the relocation constant is zero or greater than zero, 
the actual address register must contain the target address, i.e., the 
relocation constant is not included in the address in the address 
register. 

The target memories must all appear at the end of the *mems.dat file in 
an order corresponding to the order of the relocation constants 
appearing here. The memories are identified starting with 1, and are 
numbered consecutively in the order in which they appear in *mems.dat. 
The relocation constants in *iopts.dat must correspond in number and 
order to the memory contents in *mems.dat. 

W Divisor to right justify emulated address register (*) 

The power of 2 by which the 18-bit emulated address register must be 
divided to right justify the address in an 18-bit word. 

X The QM-1 control store address at which the first computer-gene rated ei 
action is to be stored ( 06 ). 

The rest will be stored contiguously. 

Z The QM-1 control store address where the first ei address register will be 
stored (06). 

The rest will be stored contiguously. 

PA The QM-1 control store address where the first ei data register will be 
stored ( 06 ) . 

The rest will be stored contiguously. 

BB The QM-1 control store address at which the first computer-gene rated eo 
action is to be stored (06). 

The rest will be stored contiguously. 


DD The QM-1 control store address where the first eo address register will be 
stored ( 06 ) 

The rest will be stored contiguously. 

EE The highest location in the control store save area 1 (to be saved in 
*save.dat) by the initialization program (06) 

The save area begins with location zero. 

FF The highest location in the main store save area 1 (to be saved 
in *save.dat) by the initialization program (06) 
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The save area begins with location zero. 

GG The highest location in the local store save area 1 (to be saved 
in *save.dat) by the initialization program. The save area 
begins with location zero. (06) 


1 Save Areas At the beginning of an emulation batch, initialized data 

structures are read from disk and stored in the QM-1 
memory. Certain of these data structures may change 
during a run, but some do not. Thus the ones which 
change are kept in the low portions of control store and 
main store so they can readily be restored before each 
run. The low word of a save area is always 0, but the 
highest word is specified by the user in *iopts.dat. 


5.4.1. 2. 4 Device Comments File 

The comments file specifies for each device listed in the file the 
descriptive comment that will appear to the right of the device name each time 
that device appears on the stack in the emulation text output file, during the 
emulation. The stack is only printed when the user requests it. This 
usually means that he is analyzing the results of the emulation at each clock 
step, or he is trying to follow the behavior of some device during the 
emulation. At such times, it has been found that with large number of devices 
in the netlist, seeing the device name on the stack is not sufficient to remind 
the user of the function of the device, and hence these descriptive comments 
are provided. Thus, when the device name appears on the stack, the comment 
reminds the user of the function of the device. 

Because of the potentially large number of devices in a netlist, an 
optional aid was provided to enable the user to produce this comments file. 

When he runs the initialization the first time, he can provide an empty 
*comm.dat file, but turn on item S in the *iopts.dat file. By doing this a 
skeleton file will be produced containing all the device names in alphabetical 
order, and then all the user need do is edit the file, adding the descriptive 
comments. For any devices for which he does not desire any comments, he can 
merely delete that device record from the file or just leave the record with no 
comment. Then he must run the initialization again, this time using the newly 
edited file as the *comm.dat file. The file produced by turning on item S has 
the following format and contents: 

Fortran Format for each Record: (1X,I4,1X,06,1X,A20) 

Contents of each Record: Device Number in decimal 

Device Number in octal 
Device Name 

The format required for the *comm.dat file is: 

Fortran Format for each Record: (13X, A20,lX,A70) 

Contents of each Record: Device Name 

Device Description or Comments 

It can be seen that the device number in decimal and octal are not needed 
but that the user can leave them and merely add the description. 
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On the other hand, if the user desires, he can create the *comm.dat file 
independently of the emulator using whatever method he desires, merely using 
the format (13 x,a20,1x,a70) . 

Following is an example of a *comm.dat file that was initially created by 
turning on item S and then editing the output file:: 


5. 4. 1.2. 4.1 Sample Device Comments File 


2 

2 

3 

3 

5 

5 

6 

6 

7 

7 

8 

10 

9 

11 

10 

12 

23 

27 

24 

30 

25 

31 

26 

32 

27 

33 

28 

34 

29 

35 

30 

36 

31 

37 

32 

40 

33 

41 

34 

42 

35 

43 

36 

44 

49 

61 

495 

757 

496 

760 

497 

761 

498 

762 

499 

763 

500 

764 

501 

765 

507 

773 

508 

774 

509 

775 

510 

776 

511 

777 

512 

1000 

513 

1001 

514 

1002 

515 

1003 

3168 

6140 

3169 

6141 

3170 

6142 

3171 

6143 


FFA'CPUIC06 

FFA r CPUICl3 

FFA'CFUIC28 

FFA'CPUIC71 

FFA0CPUIC39 

FFA0CFUIC40 

FFA0CPUIC42 

FFA0CFUIC43 

FFACPUIC06 

FFACPUIC13 

FFACPUIC21 

FFACPUIC28 

FFACPUIC71 

FFB'CPUIC06 

FFB'CPUIC13 

FFB'CPUIC21 

FFB ' CPUIC28 

FFB'CPUIC71 

FFB0CPUIC39 

FFB0CPUIC40 

FFB0CFUIC42 

FFB0CFUIC43 

FFBCPUIC06 

GA0BCPUIC29 

GA0BCPUIC32 

GA0BCPUIC35 

GA0BCPUIC38 

GA0CPUIC01 

GA0CPUIC08 

GA0CPU1C15 

GA0CPUIC45 

GA0CPUIC52 

GA0CPUIC59 

GA0CPUIC66 

GA0CPUIC70 

GA0LCPUIC29 

GA0LCPUIC32 

GA0LCPUIC35 

GA0LCPUIC38 

TSY3CPUIC39 

TSY3CPUIC40 

TSY3CPUIC42 

TSY3CPUIC43 


FOV single bit overflow flop 
IND indirect storage flop 
A* flop - repeat counter 
FLAGl 

bit 12 T register - 9407 mem addr processor 

bit 8 T register - 9407 mem addr processor 

bit 4 T register - 9407 mem addr processor 

bit 0 T register - 9407 mem addr processor 

FOV* single bit overflow flop 
IND* indirect storage flop 
IR04 - instruction register 
A flop - repeat counter 
NOT USED 

PFEIN interrupt enable flop 
LINK used by micro program 
IR05* - instruction register chip 
B* flop - repeat counter 
FLAG2 

bit 12 P register - 9407 mem addr processor 

bit 8 P register - 9407 mem addr processor 

bit 4 P register - 9407 mem addr processor 

bit 0 P register - 9407 mem addr processor 

PFEIN* interrupt enable flop 

A0* RAM latch output* - 2901 

A0* RAM latch output* - 2901 

AO* RAM latch output* - 2901 

A0* RAM latch output* - 2901 

UMA0 - micro memory prom address 

UMA0 - micro memory prom address 

UMA0 - micro memory prom address 

addr input Y08 - START ADDR PROM 

UMA0 - micro memory prom address 

UMA0 - micro memory prom address 

UMA0 - micro memory prom address 

addr input - sequence control PROM 

A0 RAM latch output - 2901 

A0 RAM latch output - 2901 

A0 RAM latch output - 2901 

A0 RAM latch output - 2901 

D14 output - 9407 mem addr processor 

D10 output - 9407 mem addr processor 

D06 output - 9407 mem addr processor 

D02 output - 9407 mem addr processor 
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3172 

6144 TSY3CPUIC62 

UMA9 



3177 

6151 TSY4CPUIC62 

SPARE 



3178 

6152 ZDUMMYCLOCK 




3179 

6153 ZGTSQ1CPUIC30 

DAT15 

- output register 

and 

3180 

6154 ZGTSQ1CFUIC31 

DAT07 

- output register 

and 

3196 

6174 ZMEM1CON2 




3197 

6175 ZSELECTCPUIC 

MICRO 

MEMORY READ 



For example, using the above as the *comm.dat file: if the device 

FFA'CPUIC06 were on the stack, the comment "FOV single bit overflow flop" would 
be printed to the right of the device name. If the device ADUMMYINPUT were to 
appear on the stack, no comment would appear, since that device does not appear 
in this file. Also, if the device ZDUMMYCLOCK were to appear on the stack, no 
comment would follow, since it appears in this file, but with no comment. 


5.4. 1.3 Initialization Output Files 
5. 4. 1.3.1 Initialized System State File 


The initialization program initializes the entire netlist, the external 
registers, and the target memories and captures this initial state of the 
entire system in a single binary file *save.dat. This file then becomes an 
input to the emulator. This file must be created each time any part of the 
netlist, target memories, device comments, or values in *iopts.dat changes. 

Once the system state file has been created to the user's satisfaction, the 
initialization need not be run again. The system state file is transparent to 
the user, other than the fact that he should be aware of its existence so that 
he does not inadvertently delete it. 

5.4. 1.3. 2 Initialization Text Output File 

The contents of the initialization text output file(*iout.dat) created by 
the initialization program are almost completely under the control of the user. 
In the input file, *iopts.dat, he specifies what outputs he wishes to appear in 
this file. 

Mandatory Outputs 

The first line of the file is the run date and time. The second line 
begins with the text "TARGET MACHINE:" and is followed by the text which the 
user inserted in item A of *iopts.dat. 

If there are any gates in the netlist which have no inputs, then the third 
line consists of the text: 

"ASSIGNMENT OF 0/1 TO FOLLOWING GATES WITH NO INPUTS:", and is followed by a 
list of devices for which no inputs were defined by the user. The initializer 
thus assigned the output value(0 or 1 as specified in item C of Hopts.dat) to 
all of these devices. If there were no such devices, this output does not 
appear. 

Optional Outputs 
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All other outputs are optional and are controlled by the user in 
*iopts.dat. The optional outputs are selected by the user in items I through T 
in *iopts.dat. See Appendix B for an example of an Initialization Text Output 
File. 


5. 4. 1.3. 3 Initialization Matrix File 

If the user is planning to run an emulation on the QM-1, he must do an 
initialization run in which he turns on item 14. This will cause the *mat.dat 
file to be generated. This is a text file which contains the initialized 
netlist in a form which can be processed by the QM-1. 


5. 4. 1.3. 4 initialization External Registers File 

If the user is planning to run an emulation on the QM-1, he must do an 
initialization run in which he turns on item 43. This will cause the 
*extrn.dat file to be generated. This is a text file which contains the 
initialized external registers in a form which can be processed by the QM-1. 
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5.4.2 Emulation on Vax 


5.4.2. 1 General 

A given network can be emulated only after it has been initialized. The 
inputs to the emulation process are : the Initial System State contained in a 
binary file produced by the initialization, the Fault List, the Runtime Options 
file, and the optional External Inputs. The Text Output file is always 
produced, and its contents depend on the options the user has selected. The 
w principle output is the optional External Outputs File(s). Other optional 
outputs are the control store and main store files for the QM-1. 


Input Files 


* save.dat 

*eopts.dat 
* fault.dat 

**.dat 


Required Input Files 

The initialized system state, including the initial 
contents of the target memories, produced in binary 
form by the initialization program. 

The run-time emulation parameters. See Section 
5. 4. 2. 2. 2. 


The fault list. 

Optional Input Files 
External Input files, named by the user 


Output Files 
Mandatory Output Files 

*eout.dat Text output which varies according to the options 

that the user has requested in *eopts.dat. 


**.dat 
*qmcs.dat 
*qmms.dat 
* summ.dat 


Optional Output Files 

External Output files, named by the user 
Control Store Initial Contents, for QM-1 
Main Store Initial Contents, for QM-1 
Timing Summary 


** User specifies entire Vax Vims file name rather than just a prefix. 
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5.4. 2. 2 Emulation Input Files 


5.4.2. 2.1 Initialized System State File 

The initialization program initializes the entire netlist, the external 
registers, and the target memories and captures this initial state of the 
entire system in a single binary file *save.dat. This file then becomes an 
input to the emulator. This file must be created each time any part of the 
netlist, target memories, device comments, or values in *iopts.dat changes. 
Once the system state file has been created to the user's satisfaction, the 
initialization need not be run again. The system state file is transparent to 
the user, other than the fact that he should be aware of its existence so that 
he does not inadvertently delete it. 


5.4.2.2.2 Emulation Run-Time Options File 

The emulation options file *eopts.dat is the input file which contains 
parameters and user selections for the emulation run. This file allows the 
user to vary the external inputs and external outputs for each run and also to 
vary what outputs he wishes to have produced for each run, without having to 
redefine the target machine, that is without having to rerun the 
initialization. The emulation options file is usually prepared manually with 
an editor. Listed below is a sample emulation options file. It can be used as 
a template for the user's preparation of his own file. Following the sample is 
a description of each of the records in an emulation options file. In order to 
facilitate the discussion, the individual records in the sample have been 
labeled on the far right with capital letters which are then referred to as 
record identifiers in the descriptions of the records. Some of the items in 
this file are no longer used or are used only for debugging purposes. For that 
reason, only the items currently used that are relevant to the general user are 
so labeled. These capital letters are merely for documentation purposes. The 
general user need only be concerned with the labeled items. The records not 
labeled with a capital letter are not used (i.e., the values are "don't care", 
but must still be present). 

All outputs requested in this file, except for external outputs, are 
produced as part of the *eout.dat file. Item Y controls the time(s) at which 
items K through Z6 will be produced. The external outputs are generated in 
user-named files (see item BBl). 

All items from A through Z7 merely control the outputs which are to be 
produced to enable the user to analyze how the emulation is proceeding. These 
items in no way affect the emulation, and it is normal to produce none of them 
once the emulation is working properly. On the other hand, items AA through 
AA3 are the specifications for the external inputs and do affect the emulation. 

See Appendix D for samples of the actual outputs produced. 
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5. 4. 2. 2. 2.1 Sample Emulation Run-Time Options File 

Following is an example of an Emulation Options File, *eopts.dat. Hie 
label for each record is a capital letter appearing to the far right of the 
record. It is for documentation purposes only, and does not actually appear in 
the record. 

The output options 1-50 are switches which control which outputs are 
produced. These options have no affect whatsoever on the emulation, but are 
merely for the user's benefit if he wishes to see the emulation process in more 
detail (especially when the emulation is not working as expected). In each 
case, a 1 means the option is turned on and the corresponding output will be 
produced, while 0 means it will not. 

Abbreviations : 

In what follows, the abbreviation ei is used for 
external inputs, and the abbreviation eo is used for 
external outputs. The abbreviation cs is used for control store, 
and ms is used for main store. An asterisk (*) preceding the 
name of a file represents the user-supplied prefix. 


Any Title 
004000,004017 
000100,000117 
000000,000010 
0 
0 
0 
1 
1 
1 
0 
1 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 


Sample *eopts.dat File 


! Title to describe the Batch 
for dump 
for dump 
for dump 

*** First Output Option*** 


cs low ,high address 
ms low, high address 
Is low, high address 

1 not used 

2 not used 

3 not used 

4 not used 

5 not used 

6 not used 

7 not used 

8 control store memory dump 

9 main store memory dump 

10 local store memory dump 

11 stack dump in full mode 

12 not used 

13 not used 

14 not used 

15 not used 

16 not used 

17 not used 

18 not used 

19 not used 

20 not used 

21 not used 

22 not used 

23 not used 

24 Memory Dumps at Stop Time 

25 not used 

26 not used 

27 not used 


NN 
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Z3r x so*q> 


1 

! 28 time line 

T 

0 

! 29 stack size 

U 

0 

! 30 stack dump in abbreviated mode 

V 

1 

! 31 insertion and lifting of gate faults 

w 

1 

! 32 not used 


1 

! 33 insertion and lifting of memory faults 

DD 

1 

! 34 partial fault list 

DDl 

0 

! 35 scheduling and insertion of external inputs 

EE 

0 

! 36 not used 


0 

! 37 not used 


1 

! 38 scheduling and generation of external outputs 

FF 

0 

! 39 not used 


0 

! 40 run numbers 

GG 

0 

1 41 fault file for QM-1 

HH 

0 

! 42 memory dumps at action-scheduling times 

II 

0 

! 43 not used 


0 

JJ 

I 44 external input list and ei registers for QM-1 


0 

KK 

1 45 external output registers for Q1-1 


0 

LL 

! 46 abbreviated run to produce QM-1 data only 


0 

I 47 not used 


0 

! 48 not used 


0 

l 49 not used 


0 

! 50 not used ***Last Output Option*** 

1,180,1 

! start, stop, delta times, for outputs 

Y 

180 

! stop time (not used) 


DEVICET 

1 Device Name(s) for Trace 

7 

***** 

! Sentinel for trace devices 

Zi 

time= 

0 004001 004013 ! User dump specifications 

Z2 

(Ix,a7,lx,i5 

,lx,o6,4x,10(il) ) ! Format for user-specified dump 

Z3 

***** 

! Sentinel for User dump selections 

Z4 

DEVICEH 

! Devices to have state info dumped 

Z5 

***** 

! Sentinel for state info. devices 

Z6 

1 

! Number of external input lists 
y.eiJtoyeil.dat Iname of file containing list 

AA 

[bb.edata.to 

AA1 

8 

I no. of bits in each data item 

AA2 

TSY2U66 

(name of fanout device 

AA3 

TSY1U66 

II 

AA 3 

TSY3U66 

II 

AA3 

TSY4U66 

II 

AA3 

TSY2U65 

It 

AA3 

TSY1U65 

II 

AA3 

TSY3U65 

II 

AA3 

TSY4U65 

II 

AA3 

1 

'.number of external output sets 

BB 

eofilel.dat 

(output file name for this eo set 

BBl 

4 

!no. of bits in each output this set 

BB2 

100 

(maximum number of items in eo buffer 

BB3 

004440 

!cs data register address this set 

BB4 

1,25,1 

(reschedule flag, start time, delta time for rescheduling 

BB5 
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5. 4. 2. 2. 2. 2 Record Descriptions for Emul. Run-Time Options File 

Description of Records in *eopts.dat File 

Formats: 

In each item, the Fortran format follows in parentheses after 
the name of the item. 

A Title (10A4) : Any descriptive title for the Batch. 

This title will appear at the beginning of the emulation 
output file *eout.dat, following the title for the 
target machine and preceded by "BATCH:" (One should be sure 
to begin any comments beyond column 40). 

F Control Store Dump Locations (06,lX,06) 

The starting address (in octal) of the block of control store to 
be dumped, followed by the ending address(in octal) of the 
block of control store to be dumped. Hie dump takes place 
only if print option 8 (item K) is on, and occurs at the 
times specified in item Y. It also takes place at termination time 
if option 24 (NN) is on. 

G QM-1 Main Store Dump Locations (06, IX, 06) 

Same as F, but for Main Store and print option 9(item L). 

It also takes place at termination time if option 24 (NN) is on. 

H QM-1 Local Store Dump Locations (06, IX, 06) 

Same as G, but for Local Store and print option 10(item M). 

K Control Store Dump Option (II) 

If this option is on, the control store range specified in item F 
will be dumped at times specified in item Y. 

L Main Store Dump Option (II) 

If this option is on, the main store range specified in item G 
will be dumped at times specified in item Y. 

M Local Store Dump Option (II) 

If this option is on, the local store range specified in item H 
will be dumped at times specified in item Y. 

N Stack Dump in Full Mode (II) 

If this option is on, the selected stack items (either the entire 
stack or a trace stack) will be dumped in the full format 
mode (see Section 5. 4. 2. 3. 2) 

NN Memory Dumps at Stop Time(Il) 

If this option is on, a control store memory dump and main store dump 

will take place at the stop time for each run. 

T Time Line (II) 

If this option is on, the time line will be dumped as a single 

line by itself. This option would only be used if item N is 

not on, and one wishes to see the time line. See Section 5. 4. 2. 3. 2. 

U Stack Size (II) 

If this option is on, the number of items in the stack will 
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be dumped, but not the stack itself. 

V Stack Dump in Abbreviated Mode (II) 

If this option is on, the selected stack items (either the complete 
stack or a trace stack) will be dumped in the abbreviated format 
mode. See Section 5. 4. 2. 3. 2. 

W Insertion and Lifting of Gate Faults (II) 

If this option is on, each time a gate fault is inserted or 
lifted, the relevant information, namely the time, the 
name of the device, and the particular action will be dumped. 

DD Insertion and Lifting of Memory Faults (II) 

If this option is on, each time a memory fault is inserted or 
lifted, the relevant information will be dumped. 

DDl Partial Fault Buffer Dump 

If this option is on, the first lOO(octal) locations and the 
last 27 (octal) locations of the fault buffer will be dumped. 

EE Scheduling and Insertion of External Inputs (II) 

If this option is on, each time an external input is 

scheduled and/or inserted, the relevant information will be dumped. 


FF Scheduling and Generation of External Outputs (II) 

If this option is on, each time an external output is 
scheduled/generated, the relevant information will be dumped. 

GG Run Numbers (II) 

If this option is on, numbers are assigned sequentially, starting 
at 1, to the runs in a batch, and are dumped at the beginning 
of each run. 

HH Fault File for QM-1 (II) 

If this option is on, a file *qmras.dat containing the fault list will 
be produced which can be sent to the QM-1 for emulation on that 
machine . 

II Memory Dumps at Action Scheduling Times (II) 

If this option is on, a control store memory dump and main store 
memory dump will take place each time an action is scheduled. 


JJ External Input Data for QM-1 (II) 

If this option is turned on, then the external input list is produced 
in file *qmms.dat for the QM-1, and the external input data and 
address registers are produced in file *qmcs.dat for the QM-1. 

KK External Output Data for QM-1 (II) 

If this option is turned on, then the external output registers are 
produced in file *qmcs.dat for the QM-1. 

LL Abbreviated Run for QM-1 File Generation (II) 
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If this option is on with any of options HH, JJ, and KK turned on, 
then the program will produce the output files for the QM-1 and stop 
without doing any emulation. Thus this should be turned on if one 
wishes to do the emulation runs on the QM-1 but not on the Vax. On 
the other hand, one can turn on items HH, JJ, and KK, and LL and 
perform emulation on both the QM-1 and the Vax. 

y Dunp Option Time Window (*) 

The start time, stop time, and time interval (in units of stacks) 
at which all the selected outputs K through Z6 will be produced. 

Z Names of Devices to be Traced (A20) 

The names of all devices which are to be traced, i.e., dumped when 
they appear on the stack. See Section 5.4.2. 3.2. If one or more 
devices appear in this item, then the full stack will not be dumped, 
but only the devices listed here (when they appear on the stack). 

Ihe names can appear in any order. If no names appear here, and 
items N and V are off, no stack will be dumped; however, the sentinel 
(item Zl) must be present in any case. If any comments are to be 
present in the record, one should be sure to begin the comment beyond 
column 20. There will be one item Z record for each device to be 
traced. 

Zl Sentinel for Trace Devices (A20) 

This record signals that no more trace device names follow. This 
record must always be present, whether or not there are any trace 
devices listed. This record must have an asterisk in each of columns 
1 through 5. 

Z2 User-Defined Dump Specifications Part 1 (A20,lX,ll,lX,O6,lX,O6) 

Items F through M allow the user to dunp portions of control store, 
main store, and/or local store at times specified in item Y. Ihe 
advantage of using items F through M is that the program produces the 
dump in a fixed format about which the user need not be concerned. 

The disadvantages of using items F through M are that only one 
contiguous section of control store, one section of main store, and 
one section of local store can be dumped, and this is always done in 
a fixed format. In order to overcome these disadvantages, one can 
use items Z2 and Z3. These items allow the user to define what he 
would like to dump and in what format he would like to see this dump. 
It is possible to define up to 15 (maxupch) different Dump 
Specifications. Each dump specification consists of two records, 
namely items Z2 and Z3. Item Z2 specifies what is to be dumped, and 
item Z3 specifies in what format the data is to be dumped. Thus it 
is possible to dump up to 15 different contiguous portions of control 
store, main store, and/or local store in user-defined valid Fortran 
77 formats. If the user does not wish to have any user-defined dump 
specifications, there should be no Z2 or Z3 records, but there must 
always be one Z4 record. 

Record Z2 contains: 

1. The literal characters or title to be printed preceding the 
dump 

2. The memory- type flag (0-control store, 1-main store, 2-local 
store ) 
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3. The starting location to be dumped 

4. The ending location to be dumped 


Z3 User-defined Dump Specifications Part 2 (A80) 

The second record, Z3, contains the Fortran format statement 
(enclosed in parentheses) in which the data which was defined in part 
1 is to be dumped. 

Z4 Sentinel for User-defined Dump Specifications (A20) 

This record signals that no more user-defined dump specifications 
follow. This record must always be present, whether or not there are 
any user-defined dump specifications. This record must have an 
asterisk in each of columns 1 through 5. 

Z5 Names of Devices for which State Information will be Dumped 

The header word for each device contains all the state information 
for that device. The user would use item Z5 if he wishes to examine 
the state(s) of one or more particular devices at specified times 
during the emulation. There should be one Z5 record for each device 
for which state information is to be produced. It should be noted 
that it is possible to have header information of a given device 
change without having the device appear on the stack (e.g., an 
enabling or disabling of a tri-state). This item may have no devices 
in it; however, the sentinel, item Z6 must always be present. 

Z6 Sentinel for State Information Devices (A20) 

This record signals that no more state information device names 
follow. This record must always be present, whether or not there are 
any state information devices listed. This record must have an 
asterisk in each of columns 1 through 5. 

AA Number of External Input Sets (*) 

If this value is zero, then items AAl through AA3 are left out. 

If this value is not zero, then the group of items AAl through 
AA3 must appear once for each external input set. 

AAl Name of File containing the external input list (A40) 

The file named here contains the actual data to be inputted 
from external sources during the run. See Section 5. 4. 2. 2. 4. 
for a complete description of this file. 

AA2 Number of Bits in each data item (*) 

This is the number of bits that must be supplied in the ei file each 
time the data is to be inserted into the network. The maximum number 
of bits is 32. 

AA3 Name of fanout device (A20) 

There must be as many devices listed as the number of bits specified 
in AA2 above. Each device will receive as input the bit specified in 
the data. The first device named will receive the most significant 
bit, and the last device the least significant bit. There will be 
one device named on each AA3 record. 

BB Number of External Output Sets (*) 
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If this value is zero, then items BB1 through BB5 are left out. If 
this value is not zero, then the group of items BBl through BB5 must 
appear once for each external output set. 

BBl Name of File to receive the output data (A40) 

The file named here will be written to at the completion of the batch 
run arid will contain the time-tagged data for this external output 
set for all runs in the batch. 

See Section 5. 4. 2. 3. 3 for a complete description of this file. 

BB2 Number of Bits in each data item (*) 

This is the number of bits that will be dumped to the external output 
file each time the data is requested. The first bit dumped is the 
leftmost bit at the address specified in BB4 , and bits are dumped 
rightward and from ascending locations. The largest acceptable value 
for this field is 126(decimal) . 

BB3 Maximum number of items in the buffer (*) 

This is the largest number of items this data set is expected to 
generate during the entire batch run. It is used for storage 
allocation. 

BB4 Control Store Address of External Output Data Register (06) 

Hie address in control store of the first data register to be dumped 
for the external output set. 

BB5 Reschedule Flag, Start Time, Delta Time for External Outputs (*) 

Reschedule flag: if this value is zero, then the scheduling of this 

external output set is controlled by internal logic, i.e., when a 
specified devices goes high, the output is produced, but otherwise 
the output is not produced. If this value is one, then the emulator 
does automatic rescheduling of this external output, starting at the 
specified start time, and at intervals of the specified delta time, 
until the end of the run. 

Start time: The first time at which this output is to be 

automatically scheduled, if reschedule flag »1 (otherwise not used). 

Delta time: The time increment between automatic rescheduling, if 

reschedule flag*l (otherwise not used). 


5.4.2.2.3 Fault List File 


5. 4. 2.2.3. 1 Contents of the File 

In the fault list file, *fault.dat, the user specifies all "operations" 
to be performed for the batch. A batch consists of one or more "runs" for 
the same target machine. A run begins at time 1 and continues until the stop 
time designated in the fault list for that run. The parameters which the 
user must supply depend upon the particular operation. 

The time given is in units of the basic clock ticks or numbers of stacks 
of the emulator. For each run in the batch, any number of operations may be 
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specified. There will be a maximum number of operations that can be 
accomodated for the entire batch, and if this number is exceeded, the user 
will be notified. Within each run, the operations must be in ascending time 
order. Valid operations, their corresponding op codes used in the fault 
list, and the parameters required for each are listed below: 


Op Code Operation 


Parameters Required 


1 

Stop Batch 


2 

Stop Run 

Time 

3 

Stick Gate at 0 

Time 

4 

Stick Gate at 1 

Time 

5 

Lift Gate Fault 

Time 

6 

Insert Fault in ROM 

Time 

7 

Lift Fault from ROM 

Time 


Gate Name 
Gate Name 
Gate Name 

Memory Id, Word Id, Bit Position 
Memory Id, Word Id, Bit Position 


Valid Op Codes 
Figure 17 


Stop Run 

The user specifies the time at which the run is to terminate. There 
must be one "stop run" operation as the last operation for each run. It is 
possible that the "stop run" may be the only operation for the run. 


Stick Gate at 0/1 

The user may apply faults to simple gates. The faults that are 
applied are "stuck at" faults. The user specifies the gate name, whether 
the gate is to be stuck at 0 or 1 (by the op code) , and at what time the 
gate is to be stuck. For a gate to be stuck at 0 means that the output 
line of the gate will remain at 0 no matter what the input values happen to 
be; when a gate is stuck at 1, the output line will remain at 1 no matter 
what the input values happen to be. The gate remains stuck until a "lift 
gate fault" is applied to the gate. 

Only simple gates may be faulted (AND, NAND, OR, NOR, XOR, NXOR). If 
one wishes to fault a flip-flop, then the flip-flop could be modeled as a 
set of gates, or a dummy gate could be inserted whose input is the output 
of the flip-flop, and the dummy gate could be faulted. If one wishes to 
fault a tri-state, the same is true as for flip-flops. 

When a user specifies that a gate is to be stuck at time T, the fault 
actually becomes effective at time T+l. If one wishes to have a gate stuck 
from the very beginning of a run (T»l), then the time given with the op 
code should be 0. 


Lift Gate Fault 

When one wishes to remove a fault from a gate, he supplies the gate 
name and the time at which the fault is to be lifted. The user should not 
request that a fault be lifted from a gate unless a fault has previously 
been inserted and not yet lifted. Again, when a user specifies that a 
fault be lifted at time T, the lifting of the fault will be effective at 
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time T+l . When the fault is lifted, the output line of the gate will then 
again accurately reflect the values on the input lines. 

It is possible in a particular run at present, to assert up to 30 gate 
fault insertions and/or lifts at the same time. This maximum can be 
increased if necessary. See Section 5.2.3. 

Insert Fault in BON 

In order to insert a fault into a RON, the user must specify the time 
at which the fault is to be inserted, the identification number of the 
particular rom, the address of the word to be faulted and the bit position 
of the bit to be faulted. Faulting a bit in a ROM is equivalent to 
complementing the correct value. 

Lift Fault from BON 

One may request that a fault which has been previously inserted into a 
ROM be removed. Removing the fault is equivalent to complementing the 
value currently in the specified bit position, or in other words, returning 
it to its original value. Note that if one tries to lift a fault which has 
not previously been inserted, then one has effectively inserted a fault, 
since the existing bit is merely complemented. When a user specifies that 
a ROM fault be inserted or lifted at time T, the operation is actually 
effective at time T. 

Stop Batch 

This operation is unique in that it may not be specified by the user. The 
emulation automatically adds a "stop batch" code at the end of the fault 
buffer. Its execution causes the entire batch job to be terminated. This 
operation is basically transparent to the user. 


5. 4. 2. 2. 3. 2 Structure of the File 

The first record of the file is a title which will be printed in the 
output file. Following the title is a list of "operations" to be executed 
for run 1, followed by operations for run 2, etc. There is no limit on the 
number of operations for each run. The minimum number of operations per run 
is one. There must be one "stop run" operation as the last operation for 
each run. In this "stop run" operation the user specifies at what time the 
run is to terminate. Each run may thus have a different stop time. It is 
possible that the "stop run" may be the only operation for the run. Thus 
every fault file must have at least two records, namely the title record and 
at least one "stop run" operation. Operations for any particular run 
consist of a sequence of operations which must be in ascending order by time. 
The structure of the file is show below (assuming n runs in the batch): 


File Structure 

Title Record 
Operations for Run 1 
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Operations for Run 2 


S 


Operations for Run n 


Record Structures 

The number of records required for each operation is dependent on the 
particular operation; however, record 1 for each operation has the same 
format. The record contents and formats are: 


Title Record 

Format: (A40) 

Contents: The first record of the file contains a title which will be 

printed at the beginning of the output file *eout.dat 
preceded by "Operations :" 


Operations for Each Run 

Valid operations, their corresponding op codes used in the fault list, 
and the parameters required for each are listed below: 


Op Code Operation 

1 Stop Batch 

2 Stop Run 

3 Stick Gate at 0 

4 Stick Gate at 1 

5 Lift Gate Fault 

6 Insert Fault in ROM 

7 Lift Fault from ROM 


Record Formats 

Stop Run (op code = 2) 

Record 1: op code, time 

Stick Gate at 0 (op code = 3) 
Record 1: op code, time 

Record 2: device name 

Stick Gate at 1 (op code » 4) 
Record 1: op code, time 

Record 2: device name 

Lift Gate Fault (op code = 5) 
Record 1: op code, time 


Parameters Requ ired 


Time 

Time, Gate Name 
Time, Gate Name 
Time, Gate Name 

Time, Memory Id, Word Id, Bit Pos 
Time, Memory Id, Word Id, Bit Pos 


format(*) 


format(*) 
format (a20) 


format(*) 
format (a20) 


format(*) 


- 79 - 



Record 2: device name 

Insert Fault in Rom (op code = 6) 

Record 1: op code, time 

Record 2: Memory Id, Word Id, Bit Position 

Lift Fault from Rom (op code = 7) 

Record 1: op code, time 

Record 2: Memory Id, Word Id, Bit Position 


Following are descriptions of the individual items in the records: 

Op Code: The one-digit code for the operation to be performed (see 
table above). 

Time: The time at which the operation is to be performed, in units 

of emulator clocks or stacks. It should be noted that for op codes 
3, 4, and 5, the sticking/lifting of the gate fault doesn't become 
effective until one clock after the time specified here. 

Device name : the name of the device which is to be faulted or to 
have the fault lifted. 

Memory Id :The memories are automatically numbered consecutively by 
the emulator, beginning with 1, in the order in which they appear in 
*mems.dat. This number is the Memory Id. 

Bit Id:The bit id is the bit position in the target machine. The 
bits are numbered with bit position zero as the least significant 
position. 

Word Id:The word id is the address containing the bit which is to be 
faulted. The word id is the actual target machine address if the 
emulator has performed the relocation to the QM-1 memory, but must be 
the absolute QM-1 address if the user did the relocation manually. 

See Section 5. 4. 1.2. 3. 2, items VI... Vh for a discussion of memory 
relocation. 

Comments in Records: 

Any record with * format can have a space after the last number and 
the rest of the record can contain comments. Any record with an A 
format can have comments after the last column specified for the 
character string. 


5. 4. 2. 2. 3. 3 Sample Fault List File 

Insert and Lift Gate and Memory Faults ! Title 

4,5 !Run 1: stick gate named AND43 to 1 at time 5 

AND43 

2,40 I stop run 1 at time 40 

3,12 !Run 2: stick gate named AND44 to 0 at time 12 

AND44 


format (a20) 


format(*) 

format(*) 


format(*) 
format( * ) 
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4,12 

OR62 

5,50 

AND44 

2,100 

6,60 

3,1000,13 

7,70 

3,1000,13 

2,150 


! stick gate named OR62 to 1 at time 12 

! lift fault from gate named AND44 at time 50 

! stop run 2 at time 100 

!Run 3: insert fault in ROM at time 60 
1 stick bit 13 of word 1000 in memory 3 

! lift fault from ROM at time 70 

! lift from bit 13 of word 1000 in memory 3 

1 stop run 3 at time 150 


5. 4. 2. 2. 4 External Input Files 

For each external input set that exists, the user must create one external 
input file for which he specifies the Vax Vtas file name. No external input 
files are necessary if item AA in *eopts.dat is zero. 


5. 4. 2. 2. 4.1 Contents and Structure of External Input Files 

If item AA of file *eopts.dat is not zero, then one external input 
file must be created by the user in any manner he chooses for each 
external input set. The format for each such file is described 
below: 

The file containing the actual external inputs list consists of 
one record for each insertion of an external input. Each record 
contains the time followed by the data bits to be inserted, in the 
following format: 

(bn,il0,lx,oll) 

The times for a given set must be in ascending order, and the data 
bits must be right justified. The maximum number of bits to be 
inputted in one data item is 32. 


5. 4. 2. 2. 4. 2 Sample External Input Files 

Following are the entries in *eopts.dat which specify external input files: 


4 

combeil.dat 

7 

TS2G01 

TS2G02 

TS2G03 

TS2G05 

TS2G06 

TS2G07 

TS2G08 

combei2.dat 

1 


Inexinp no. of ei lists 

!file name of first ei list 
!no. of bits in first list 
Inames of devices feeding this list 


!file name of second ei list 
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TS2G00 

combei3.dat 

1 

TS1G00 

combei4.dat 

1 

TSlGOl 


ifile name of third ei list 
I file name of fourth ei list 


Following are contents of file COMBEIl.DAT 

I 500 combeil.dat bal-bd2 


Following are contents of file OOMBEI2.DAT 

1 0 combei2.dat ts2g00 — bal 

18 1 

28 0 


Following are contents of file OOMBEI3.DAT 
1 0 cambei3.dat tslgOO 


Following are contents of file OOHBE14.DRT 


i t> 

40 1 

61 0 

180 1 

201 0 


combei4.dat tslgOl 


5. 4. 2. 3 Emulation Output Files 


5.4.2.3.1 Text Output File 

The contents of the emulation text output file(*eout.dat) created by the 
emulation program are almost completely under the control of the user. In the 
nan options file, *eopts.dat, he specifies what outputs he wishes to appear in 
this file. See Appendix D for ten different samples of outputs produced by 
specific settings in *eopts.dat. Below is an explanation of these ten 
examples : 

Outputs Which Appear in Every Run 
Example 1: 

1 Actual Date and time the run began. 

2 Text which the user inserted in item A of file *iopts.dat. 

3 Text which the user inserted in item A of file *eopts.dat. 

4 Text which the user inserted as the first line in the file *fault.dat. 

5 Emulation time at which the run completed. 

6 Average stack size, minimum stack size, and maximum stack size over the 
entire run. 

7 Actual Date and time the run ended. 


Optional Outputs 


- 82 - 



All other outputs are optional and are controlled by the user in file 
*eopts.dat. The optional outputs are selected by the user in items F through 
Z6 in *eopts.dat. See Appendix D for examples of all of these outputs. Below 
are explanations for the examples. 

Example 2: 

Run Numbers (Item GG, Print Option 40) 

1 The number of the run within the batch, (the runs are automatically 
numbered by the program in the order in which they occur in the 
fault file. 


Stack Size (Item U, Print Option 29) 

2 Slack size, i .e. , the number ul devices on the orient sta<k, in 
octal . 

3 Current time, in octal. 

4 Stack size, in decimal. 

5 Current time, in decimal. 

Termination Dump (Item NN, Print Option 24) 

6 Dump, in octal, of control store, local store, and main store at 
Termination Time. 


Example 3: 

Control Store Dunp (Item K, Option 8) 

1 Current time, in octal. 

2 Current time, in decimal. 

3 Address of first control store location dumped, in octal. 

4 Contents, in octal, of successive control store locations, 
beginning with address in 3 above. 

Main Store Dung> (Item L, Option 9) 

5 Current time, in octal. 

6 Current time, in decimal. 

7 Address of first main store location dumped, in octal. 

8 Contents, in octal, of successive main store locations, beginning 
with address in 7 above. 

Example 4: 

Time Line (Item T, Option 28) 

1 Current time, in octal 

2 Current time, in decimal 

3 The average size of the full stack as of the current time 

4 The size of the smallest stack as of the current time 

5 The size of the largest stack as of the current time 
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6 The static average fanout for the netlist, i .e. , within the 
specified netlist, the average number of devices to which a device 
feeds. 

7 The dynamic average number of destination devices examined for each 
source device on the stack, i.e., the average fanout for the 
devices which have been on the stack through the current time. 

8 The dynamic average number of destination devices enqueued for each 
source device on the stack, i.e., the average number of devices 
whose output values have changed per each source device which has 
been on the stack through the current time. 

Example 5: 

Stack Dump in Abbreviated Mode (Item V, Option 30) 

1 Current time, in decimal. 

2 Name of Device on stack. 

3 Value on output line of device named. 


Example 6: 

Insertion and Lifting of Gate Faults (Item W, Option 31) 

1 Time at which fault was inserted, in octal. 

2 Time at which fault was inserted, in decimal. 

3 Value at which the output line of the gate was stuck. 

4 Name of the device which was faulted. 

5 Time at which fault was lifted, in octal. 

6 Time at which fault was lifted, in decimal. 

7 Name of the device whose fault was lifted. 

Example 7: 

Insertion and Lifting of Memory Faults (Item DD, Option 33) 


1 Time at which fault was inserted, in octal. 

2 Time at which fault was inserted, in decimal. 

3 Memory Id into which fault was inserted. 

4 Target Address into which fault was inserted. 

5 Target Bit Number into which fault was inserted. 

6 Absolute (^1-1 address which holds faulted word. 

7 Contents of QM-1 address prior to faulting. 

8 Bit position of faulted bit, in QM-1 word. 

9 Contents of (91-1 address after faulting. 

10 Time at which fault was lifted, in octal. 

11 Time at which fault was lifted, in decimal. 

12 Memory Id from which fault was lifted. 

13 Target Address from which fault was lifted. 

14 Target Bit Number from which fault was lifted. 

15 Absolute QM-1 address which holds fault to be lifted. 

16 Contents of QM-1 address prior to lifting. 

17 Bit position of faulted bit, in (91-1 word. 

18 Contents of QM-1 address after lifting. 
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Example 8: Trace Stack (Items Z and Zl) 

All items are the same as for example 10, except that item 9 will read 

"Trace Stack", and the only devices which will be outputted when they 

are on the stack are those whose names are listed in item Z of 

*eopts.dat. 

Example 9: Device State information (Items ZB and Z6) 

1 Current time, in octal. 

2 Current time, in decimal. 

3 Device Index Number. 

4 Device Name. 

5 Device Header Word, in octal (contains state information). 

6 The QH-1 address of the header word for this device, in octal. 

Example 10: 

Stack Dump in Full Mode (Item N, Print Option 11) 

1 Time of stack dump, in octal 

2 Tine of stack dump, in decimal 

3 The average size of the full stack as of the current time 

4 The size of the smallest stack as of the current time 

5 The size of the largest stack as of the current time 

6 The static average fanout for the netlist, i.e., within the 
specified netlist, the average number of devices to which a device 
feeds. 

7 The dynamic average number of destination devices examined for each 
source device on the stack, i.e., the average fanout for the 
devices which have been on the stack through the current time. 

8 The dynamic average number of destination devices enqueued for each 
source device on the stack, i.e., the average number of devices 
whose output values have changed per each source device which has 
been on the stack through the current time. 

9 Description of what Selection Attribute the stack has, namely a 
"Complete" stack or a "Trace" stack 

10 Sequential number representing the position of this item on the 
stack 

11 The device index number of this device, in decimal. 

12 The QM-1 address of the header word for this device, in octal. 

13 The device name. 

14 The value on the output line of the device. 

15 The header word for this device, in octal. 

16 The header word for this device, in binary. 

17 The descriptive comment listed for this device in the Device 
Comments File. If no comment was given for this device, this field 
is blank. 


5.4. 2.3.2 Stack Outputs 

A stack dump consists of a list of devices which are on the current stack. 
This dump has two attributes, namely the selection attribute and the format 
attribute. The selection attribute controls which devices will be selected for 
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printing, and the format attribute controls what information will be printed 
for each device that is selected. The attributes are selected by the user in 
the run options file *eopt.s.dat (see Section 5. 4. 2. 2. 2) 


Selection Attribute: 

Complete-Stack Mode : 

In this mode, all devices that are currently on the stack are 
printed. 

This mode is used if no device names are listed in item Z, and 
either item N or V is turned on. 


Trace-Stack Mode : 

In this mode, the user is attempting to trace the activity of 
specific devices and does not wish to see all the devices which are 
on the stack. He thus selects in item Z only the specific devices 
wfyich he wishes to "trace", and when the stack is dumped, only those 
devices which he has selected will be dumped. 

This mode is used if at least one device name is listed in item Z. 
Format Attribute: 

Full Mode: 

In the full mode, the first line is always the Time Line which 
contains the current time in octal and in decimal, the average stack 
size, the minimum stack size, the maximum stack size, the average 
static fanout, average dynamic fanout examined during processing of 
stacks, and average dynamic fanout changing in value. Following the 
time line, every selected device from the current stack is dumped 
with its position on the stack, the device identification number, 
the header address in octal, the device name, the header contents in 
octal and in binary, and the user-supplied device description (if 
any) from *comm.dat. 

Full mode is selected by turning on option 11 (item N). 

Abbreviated Mode: 

In the abbreviated format mode, no time line is printed, and each 
device selected is printed in an abbreviated mode. For each device 
that has been selected, the only items printed are the current time, 
the device name, and the output value of the device. 

Abbreviated mode is selected by turning on option 30 (Item V). 

Note: If neither full mode nor abbreviated mode is selected, then 

full mode will be used. If both full mode and abbreviated mode 
are selected, then abbreviated mode will be used. 


Following is a table showing the results of all combinations of input 

options: 
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item N Item V Item z Result 


0 

0 

no device 

Selection 
no stack 

Format 

0 

0 

some device 

Trace 

Full 

0 

1 

no device 

Complete 

Abbreviated 

0 

1 

some device 

Trace 

Abbreviated 

1 

0 

no device 

Complete 

Full 

1 

0 

some device 

Trace 

Full 

1 

1 

no device 

Complete 

Abbreviated 

1 

1 

some device 

Trace 

Abbreviated 


(See Section 5. 4. 2. 3.1 and Appendix D for examples of stack outputs.) 


5.4. 2. 3. 3 External Output Files 

For a given batch, there may be zero or more external output files 
created. See Section 4.3.10.5 for a discussion of external outputs and Section 
5.2.5 for a discussion of setup of external outputs. An output file will be 
written for each external output set at the completion of each batch. 


5. 4. 2. 3. 3.1 Contents and Structure of External Output Files 

In *eopts.dat, the user specifies the Vax Vims name he has selected for 
each external output file. For a given batch, the user-specifications for a 
specific external output set are the same for each run, but the outputs 
produced will probably differ from run to run due to the differences in the 
fault list for each run. Within each output file in ascending time sequence 
will be one entry for each time the external output action was triggered. 

Within a given external output file, the first entry for run i+1 will 
immediately follow the last entry for run i. Each entry consists of the time 
the action was triggered followed by the data at that time. The format for one 
entry is: 

From the Vax Emulator: (112/(1007)) 

From the QM-1 Emulator (after being transferred to Vax): (lx, 1007) 


One could process the external output files directly in either of of these 
formats; however, if one wishes to convert the QM-1 format to the Vax format, 
see Section 5. 4. 2. 5. 


5.4.2. 3. 3. 2 Sample External Output File 

Following are items from *eopts.dat which specify external output sets: 


3 

combeol.dat 

7 

500 

004003 

0 , 1,1 


!no. of external output sets 
(file name for first eo set 
(number of bits in each entry 
(max no. of items in eo buffer 
(control store address of data register 
(reschedule flag, start time, delta time 
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combeo2.dat 
6 

500 

004004 

0 , 1,1 

combeo3.dat 
14 
500 

004006 

0 , 1,1 

Following is external output file OOMEBOl.DftT: 
40000 

34 

40000 

48 

240000 

62 - 

24000 

76 

0 

90 

0 

104 

40000 

118 

40000 

132 

40000 

146 

40000 

160 

40000 

174 

40000 

188 

240000 

202 

24000 

216 

0 


5. 4. 2. 4 Running Emulator on Vax 

.j 

Notation: 

user represents the name of the user's root directory (without the 
brackets). For example, if the user's root directory is [Smith], then in 
this document, user represents Smith. 

f 

I 


Ifile name for second eo set 


!file name for third eo set 
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Userdata represents the directory and prefix name of the user's data 
files. For example, if the directory holding the data is named 
( smith. data] , and all input files begin with prefix "counter", i.e., they 
are named counternet.dat, countermems.dat, counteriopts.dat, 
countercomm.dat, countereopts.dat, and counterfault.dat, then in this case 
Userdata represents [smith. data] counter. 


Underlining implies a command which the user inputs to Vax VMS. 


Make addition to login.com file. 

Insert a command into your login.com file which sets the symbol 
"demuser" to the name of your root directory (without the brackets). For 
example , if the name of your root directory is [Smith], then insert the 
following command into your login.com file: 

$demuse r: =Smi th 


TO Run Initialization 

1. Prepare input data files. 

2. $@[user .dem.run]iemu Userdata 


TO Run Emulation 

1. Prepare input data files. 

2. $@[user .dem.run]emu Userdata 


Example: 

Assumptions : Command files will reside on directory [smith.dem.run] 

Data will reside on directory [ smith. data] , and prefix for all data 
files is "counter". 

1. Create input data files with prefix "counter" on directory [ smith. data] . 

2. $g[ smith. dem. run ]i emu [smith. data] counter (Run initialization) 

3. $@[ smith.dem.run] emu [smith. data] counter (Run emulation) 


5.4. 2.5 External Outputs Postprocessing 


Reason for External Outputs Conversion 

When the emulation has been performed on the Vax computer, the external 
outputs file is generated with format (112/(1007)) for each external output 
record. 
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External output files which have been produced as a result of running an 
emulation on the QM-1 and which have been transferred back to the Vax are in 
QM-1 format which is: (lx, 1007) 

One could choose to process, on the Vax, the external output file from the 
QM-1, as is, and then no conversion would be necessary; however, if one 
wishes the external output file from the QM-1 to be in the same format as 
the external output files produced by the Vax emulator, which is: 
il2/(1007), then one could use the external outputs conversion program. 

It should be noted that the current form of the conversion program assumes 
there are four QM-1 words outputted for each external outputs triggering; 
one could modify the source code if this number is different from four. 


EoQMI format represents the directory and file name of the external output 
file which was transferred from the QM-1 to the Vax after the 
QM-1 emulation run. 

EoVaxformat represents the directory and file name of the external output file 
which has been converted to Vax format. 


Make addition to login.com file: 

Insert a command into your login.com file which sets the symbol 
"demuser” to the name of your root directory (without the brackets). For 
example, if the name of your root directory is [Smith], then insert the 
following command into your login.com file: 

$demuse r : *»Smi th 

Note: (Underlining implies a command which the user inputs to Vax Vtas.) 


To make changes to existing conversion Program: 

$ set default [user. dem. emulator] 

Edit appropriate fortran module (either conveoqv or tconveoqv 1 ) in 
[user . dem. emulator ] 

Do Fortran compiles of appropriate module(s) 

$ @[user .dem.run]linkconveoqv (links conversion programs) 


To Bun Conversion 


Transfer external output file from QM-1 to Vax on Userdata 

$ @[user .dem. run]conveogv EoQMIformat Eo Vax format 

(to convert without setting of high-order time bit) 1 , or 
$g[ user. dem. run] tconveoqv EoQMIformat Eo V ax format 
(to convert with setting of high-order time bit) 1 
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Example: 


Assumptions: Programs will reside on directory [ smith. dem. emulator], 

data will reside on directory [ smith. data] , and prefix for all data 
files is "counter". 

1. Transfer external output file from QM-1 to Vax on [smith. data] 

The external output file transferred from the QM-1 is 
counterqmleo.dat, and the new file in Vax format is to be named 
counterVaxeo . dat : 

3. $@ [ smi th . dem . run ] conveoqv [ smi th . da ta ] counte rqmleo . dat 

[ smi th . data ] counte rVaxeo . dat 


1 During the transfer from the QM-1 to the Vax, the two high order bits of 
eighteen are not transferred (i.e., only 16 bits are transferred). If 
these two high order bits are not needed, use conveoqv. If the high order 
bit is needed, use tconveoqv. 


5.4.3 Emulation on QM-1 

5.4.3. 1 Creation of QM-1 Files: 

A. Use Nova Files Utility to create the following files: 
(assume * is the user-selected prefix for all the files) 


*:E 

*COMP 

*CS 

*CS:S 

*EXT 

*EXT:S 

★MAT 

*MAT:S 

*MEMC 

*MEMC:S 

*MEMM 

*MEMM:S 

*MS 

*MS:S 

*PAR 

*PAR:S 

*TCOMP 

When the Diagnostic Emulation System Tape was restored to disk, three 
sets of files beginning with the prefixes "ONEC", "GF01", and "GF02", 
were created on user 6 of the disk. If one wishes to use any of these 
prefixes, he can make use of these files and thereby not have to 
create his own. In any case, ONECPAR : S and ONEC:E should be copied to 
create *PAR:S and *E:S respectively. 

B. Use Editor to customize *TCOMP AND *:E. 

The references to all data files must be changed to contain the 
appropriate prefix. 
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C. Use Editor to customize *PAR:S and *:E. 

The following control store locations must contain the specified 
values: 

Location 


147 

601 

602 

603 

605 

613 

614 

615 


5.4. 3. 2 Data Preparation 

A. Preparation of Data for Target Computer 

(theoretically this step only need be done once) 

1. Conversion and transfer of Memories file, *mems.dat. 
a)On Vax Side: 

1) Be sure all references to devices in *mems.dat have a 'D' or 'd* 
in column 1 instead of 'C f or 'c' (see()). 

2) $g ( user . dem . run ] convmems Usgrdata 

This step produces a file *memsq.dat which is memories file in 
QM-1 format. 

3) Use a Vax editor to split *raemsq.dat into *meme.dat and 
*memm.dat, where *memc.dat is the control store part and 
*memm.dat is the main store part. 

4) Use the Vax-to-QM-1 Transfer program to transfer *memc.dat 
from the Vax to the QM-1. 

5) On the QM-1 side: 11 COPYSN DESTFILE *MEMC:S 

6) Use the Vax-to-QM-1 Transfer program to transfer *memm.dat 
from the Vax to the QM-1. 

7) On the QM-1 side: 1ICOPYSN DESTFILE *MEMM:S 


Value 

address of top of first stack) + 1 

address of memory control block 

number of memory control records 

memory master control store address 

free space address 

address of main store fault block 

control store address of faulting device 

address of operations action data structure 


2. Transfer of Net List and External Registers. 

a)Run initialization program on Vax with print option 14 and print 
option 43 turned on. 

This produces a file *mat.dat, which is the netlist in QM-1 
format, and a file *extrn.dat, which is the file of external 
registers in QM-1 format. 

1) Use the Vax-to-QM-1 Transfer program to transfer *mat.dat from 
the Vax to the QM-1. 

2) On the QM-1 side: ! 1 COPYSN DESTFILE *MAT:S 

3) Use the Vax-to-QM-1 Transfer program to transfer *extm.dat 
from the Vax to the QM-1. 
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4) On the QM-1 side: UCOPYSN DESTFILE *EXT:S 


3. Assemble Target Data on QM-1: 

Press Master Clear, Start 
???LDNOV 
JUSER 6 
l EX /*TCOMP 


B. Preparation of Data for Batch Run (do this step for each batch run) 

1. Run emulation on Vax with the following options turned on: 

Turn on print option 41 to produce fault list for QM-1. 

Turn on print option 44 to produce external input registers and 
external input list for QM-1, if using external inputs. 

Turn on print option 45 to produce external output registers for QM- 

1 . 

Turn on print option 46 if do not want emulation performed on Vax. 
(i.e., if only purpose of run is to produce ©4-1 outputs) 

This produces a file *qmms.dat. This file contains the fault list 
in QM-1 format, and the external inputs list, if option 44 was 
turned on. 

This produces a file *qmcs.dat which contains external inputs data 
registers and address registers if option 44 was turned on, and/or 
external outputs data registers and address registers if option 45 
was turned on. 


2. Use the Vax-to-QM-1 Transfer program to transfer *qmms.dat from the 
Vax to the QM-1. 

3. On the ©1-1 side: U COPYSN DESTFILE *MS:S 

4. Use the Vax-to-QM-1 Transfer program to transfer *qmcs.dat from the 
Vax to the QM-1. 

5. On the QM-1 side: U COPYSN DESTFILE *CS:S 

6. Assemble Batch Data on ©1-1: 

Press Master Clear, Start 
???LDNOV 
IUSER 6 
I EX /SETUP 


5.4. 3. 3 To Run Emulation on QM-1: 

Press Master Clear, Start 
??? LD6/R* 


c- 
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5.4. 3.4 To Send QM-1 External Outputs to Vax 


A. On QM-1 Side: 

Press Master Clear, Start 
???LDEASY 
SET DATE AND TIME 
! ! DATE, XX/XX/XX 
! ! TIME, XX/XX/XX 
!!| 

i IDIRectory, Search lst=06,2nd«,08 
! ! DEADSTART 

! ! EASY-SPACE , BS=26 , TPS-347777 
I 1 <CR> 

hexec EorrooiSK 

B. Use QM-l-to-Vax Transfer program to transfer QM-1 external output file 
from QM-1 to Vax. 

On QM-1 side: 

! !EXEC QMlVAXI 

QM-1 TO Vax PIO TRANSFER FROM MEMORY 
INTERMEDIATE PRINTOUTS? ENTER Y OR N 


On Vax Side: 

$tqmlvaxi 

(type in Vax output file name when requested) 

2. Convert external outputs if desired, (see Section 5. 4. 2. 5) 


5.4.4 Vax <--> Qml File Transfers 


5.4.4. 1 Vax to Qml Transfers 

Underlined characters are those which the user types into the Operating 
System. 


step 1: (QM-1 side) 

Mount Application Pack on QM-1 Drive 0. 
Disk should be write-enabled. 


Master Clear, Start 
???L DEASY 
I ! DATE , XX/XX/XX 
! ! TIME , XX/XX/XX 

!!l 

! I DIRECTORY, SEARCH 1ST=06,2ND»,08 
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IIEX(ec) TVAXQMl 

you will then see on the screen: 

1 1 test , entry=vaxqml , file=bbvaxqml . 
vax to qml file transfer 

step 2: (Vax side) 

$ @[user.dem. transfers. vaxqmlltyqi FILENAME (where "FILENAME" is name of 
the vax file to be transferred) 


When transfer completes: 

On Vax side, file "translog.dat" contains the transmission log. 
On QM-1 side, the new file is in DESTFILE. 


optional step 3: (QW-1 side) 

(do this step only if transferred file is to be used under Nova Operating 
System) 

! 1C0PYS N DESTFILE NOVAFILE 

(where "NOVAFILE" is the name of the Nova file) 


5. 4. 4. 2 Qml to Vax Transfers 


Underlined characters are those which the user types into the Operating 
System. 


step 1: (QM-1 side) 

Mount Application Pack on QM-1 Drive 0. 

Master Clear, Start 
???L DEASY 
! ! DATE , XX/XX/XX 
! ! TIME, XX/XX/XX 
ill 

!! DIRECTORY, SEARCH 1ST*06,2ND»,08 
! lEXlec) TQMlVAXI 

you will then see on the screen: 
! !test,entry=mv,file=bbmv. 
qml to vax file transfer 


step 2: (Vax side) 

$ @[user .dem. transfers. qmlvax]tqv FILENAME (where "FILENAME" is name of the 
Vax file to be created) 
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When transfer completes : 

On Vax side, the new file is in "filename" 

On QM-1 side, file "translog" contains transmission log. 
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Appendix A 

Additional Figures 



Event, Free Space, and Action List Layouts 






Event and Free Space Record Layouts 


word 1 
word 2 
Word 3 


Word 1 
word 2 
word 3 


Control Store 
Event Record Layout 


17 

16 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 


Time at which event is to occur 


Pointer to next event in event list (null for last entry in list) 
Pointer to first action in action list to be executed at this time 


Free Space Record Layout 


[17 

16 

15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

□ 


Not Used 


Pointer to next record in free space list (null for last entry) 

Not Used 




Action Control Block Layout 


Control Store 


17 16 15 14 13 12 11 10 9 8 7 6 5| 4| 3| 2 

CONTROL BITS 

Pointer to action corresponding to control bit 17 
delta t for bit 17 

Pointer to action corresponding to control bit 16 
delta t for bit 17 


Pointer to action corresponding to control bit 0 


delta t for bit 0 


CONTROL BITS 


<~l 

A 

C 

t 

i 

O R 
n e 
c 

C o 
o r 
n d 
t s 
r 

0 

1 


rr o 



Scheduling an Event 

Insert New Event at Bead of Event List 


Old Head of 
Event List > 


NEW EVENT 


«««««< 


New Time 


NEW HEAD OF 
««EVBfT LIST 


<-> 


Insert New Event Between two Events 

HEAD OF 

EVEOT LIST > | | 



Insert New Event at Tail of List 

HEAD OF ! 

EVENT LIST > 


<-l 


»» Pointer after scheduling 

Pointer before scheduling 

Pointer which has not been 

changed by scheduling 





New Time 




null 

»»»»»> 

null 
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Scheduling an Action 


Always insert New Action at Head of Action List 
Event Action Action 



»»> new pointer after scheduling 

old pointer before scheduling, which has been replaced 

pointer which has not been changed by scheduling 
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Flip-Flop Trigger Chart 
( for downward edge-triggered flip-flop) 




( no change ) 

1 1 
1 0 
0 1 

( no change ) 

( no change ) 

0 1 
1 0 

(or indeteminant 
if R-l) 

( no change ) 

( no change ) 

( no change ) 


( no change ) 


( no change ) 
0 1 

1 0 


iQ, iQ, 

(or indeteminant if R>1) 


( indeteminant if IM. and 
J or K changed while 1>1; 
no changes otherwise) 




Q external value at time n 
Q external value at time n+1 
Q internal value at time n 
Q internal value at time n+1 
transition from 0 to 1 
transition from 1 to 0 
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Fortran Initialization I/O Units 


inputs 


Fortran 

Variable 

Name 

Logical 

File 

Name 

Vax VMS 
File Name 

Description 

UIN 

POR008 

♦net.dat 

the target network description netlist) 
in DENF format 

UINO 

POR007 

* conan.dat 

the comments or descriptions to appear 
alongsode device names when they 
appear on the stack output 

UINl 

FOROIO 

*mems . dat 

the initial values to be resident in 
the host memory before the emulation 
begins 

UIN2 

POR011 

♦iopts.dat 

Outputs 

the user runtime initialization parameters 

Fortran 

Variable 

Name 

Logical 

File 

Name 

Vax VMS 
File Name 

Description 

UOUT 

POR014 

♦iout.dat 

output text file from initialization 

UOUTl 

POR012 

♦alph.dat 

alphabetic list of devices: 
device name, device number, 
device type, device class, 
initial output value 

U0UT2 

FOR013 

* nara.dat 

template for creating *comm.dat 
device number, device number, 
device name 

U0UT3 

POR019 

*mat.dat 

entire matrix in format to go to QM-1 

U0UT4 

FOR020 

♦check. dat 

debugging information 

UOUT5 

FOR021 

♦save.dat 

all initialized data structures in 
binary form 

U0UT8 

FOR028 

♦extrn.dat 

control store externals to go to QM-1 
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Fortran Emulation I/O Units 


Inputs 


Fortran 

Logical 

Vax VMS 

Variable 

File 

File 

Name 

Name 

Name 

UIN2 

FOROll 

*eopts.dat 

UIN3 

FOR015 

*fault.dat 

UIN4 

FOR016 

(user name) 

UIN6 

POR009 

*save.dat 


Outputs 


Fortran 

Logical 

Vax VMS 

Variable 

File 

File 

Name 

Name 

Name 

UOUT 

FOR014 

♦eout.dat 

U0UT6 

FOR026 

(user name) 

U0UT7 

FOR027 

*qmms.dat 

U0UT9 

FOR029 

* qmcs.dat 


Description 


user runtime options for emulation 
fault list 

external input lists 
all initialized data structures 
(in binary) created 
by initialization pro9ram 


Description 


text output file from emulation 
external outputs files 
main store contents to 90 to QH-1 
control store contents to 90 to QM-1 


User Modifications to Fortran Module to Execute One Action 


c *********** Make changes where indicated by " ++-H-+++-H i < hh-h~h-+-h-h-++ " 


C$$$$$$ EXlACT EXECUTE ONE ACTION 

C INPUTS :GPA - PTR TO ACTION TO BE EXECUTED 

C OUTPUTS: EXECUTED ACTION 

C IF INVALID ACTION CODE, PRINT ERROR & STOP 

SUBROUTINE EXlACT 
IMPLICIT INTEGER (A-Z) 

INCLUDE 'CQMM20.FOF/list' 

INCLUDE ' COMM21. FOR/1 i St' 

INCLUDE 'COMM22.POR/list' 

INCLUDE 'EKUPARAM. FOR/1 i St' 

C****** ***************************************************************** 

LOGICAL*l CFALSE 
DATA CFALSE/. FALSE./ 

DATA LMCODE/' 774000 '0/ 

C INCLUDE 'GETCS.FOR/list' 

INCLUDE 'CLEAR. FOR/1 i St' 

C EXECUTE ACTION 
LACT=CS ( GPA) 

LACODE= ( LACT .AND . LMCODE )/DIVACT ! ACTION OCX® RIGHT JUSTIFIED 

GOTO (10,20, 30,40,50,60,70,80) ,LACODE JAIRLAB ACTIONS 

IF( (LACODE.GE.ILLACl ) .AND. (LAOODE.LE.ILLAC2) )GO TO 500 !U.OF ILL. 

C-H-+ WH ++t H+-K+ 'f+ t+HH+ + H I I I | +++++++++++4 )-+-)-++++++++4-+ + t I H t i ll + ■» ) » f H -+ > | f 

c *** Insert "IF" here checking for new action code and branch to newly 
inserted call to user-written action*** , for example : 

C IF ( LACODE . EQ . NEWCODE ) GO TO 600 

I I I I l+»H I I i+- H -++f- H -++- H -+++-> -H H -++ t t ♦ H-+++++++++++ H I H-H-H 

WRITE ( UOUT , 1000 ) gpa , LACT , LACODE 

call termrn 

STOP 

C ACTION 1 - FILL BUFFER 

10 CALL ACTl 

GO TO 250 

C ACTION 2 - WRITE MEMORY 

20 CALL ACT2 

GO TO 250 

C ACTION 3 - READ MEMORY 

30 CALL ACT3 

GO TO 250 

C ACTION 4 - DUMP NON-EMPTY BUFFER TO DISK 

40 CALL ACT4 

GO TO 250 

C ACTION 5 - STOP RUN 

50 CALL ACT5 

GO TO 250 

C ACTION 6-EXECUTE OPERATIONS 

60 CALL ACT6 

GO TO 250 

C ACTION 7-EXTERNAL INPUTS 

70 CALL ACT7 
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User Modifications to Fortran Module to Execute One Action 


GO TO 250 

C ACTION 8-EXTERNAL OUTPUTS 

80 CALL ACT8( .FALSE. ) {NORMAL WRITE, NOT END OF RUN MARKER 

GO TO 250 

C ACTIONS FOR UNIV. OF ILLINOIS 

500 CALL ACTILL ( LACODE ) 

GO TO 250 

C+++++++++++++++++++++++++'f+ 1 - + +++++ i t+++++++ , f+++-H-++++++ +■++■++ 4 444 44-4 4 4 f 4 4 M +- H f 

C*** Insert call to new module followed by GO TO 250 *** , for example: 

C Also compile and link NENSUB as described in ( ) . 

600 CALL NEWSUB 

GO TO 250 

C+ + + + +++- H-H"H t 444 4-4-4--H-4-+-4-++4-4 - 4- -H-4-4-4- 4- 4 1 4-4- 4- 4- 4- 4 4- 4 4 1 4-4 1 4 4- 4^ 4 H1 f 4 4 I 4 4 I »4444 4 44 4 44 4 444 4 

C DO RESCHEDULINGdd 
250 IF( (LACT.AND.CMASK( 18) ) .EQ.0)THEN 

CALL PUTCS(GPA,CLEAR(LACT,CMASK( 10) ) ) 

ELSE 

CALL REACT 
ENDIF 
300 RETURN 

1000 FORMAT/ INVALID ACTION - address- f ,o6,'word 1- 
x 06/ action code- ',110) 

END 
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Fortran Parameters & Common Variables, Sorted by Common Label 

Name Dimension Common Description 

LaEeT 


maxconn pararaeter-max no. of internal connections allowed 

maxgate parameter-max no. of gates allowed 

xname (4000) co6 character*20-device names, set by getdevn 

prloc (3,2) co8 low & high address for cs,ms,ls for output 

prsw (50) co8 user print option switched, 0-off, 1-on 

prtime (30) co8 print window 1-start , 2-stop, 3-delta 

prtisw (10) co8 1-print window flag(l-on) 

nconnec comml no. of connections, set by preproc 

nextern comml no. of external connections, set by preproc 

ngates comml no. of devices, set by initrn-neqn 

runtitle(lO) comml title for run, read in getparm from eopts file 

title (10) comml i*4-title for output, read from opts file by initrn 

xaddres (4000) comml qml control store address for header for device i 

xconn (10000) comml full address for internal connection 

xhdr (4000) comml header for each device i 

xhigh (4000) comml index to connection list for last conn for device i 

xlink (10000) comml first word of internal connector record 

xlow (4000) comml index to connection list for first conn for device i 

zptr (10000) comml the index of the dest device for this connection 

xcount (4000) commll initial value of "count" for each device 

xstack (4000) commll stack flag for device (0-not on,l«is on 1st stack) 

datebuf comml4 character*9-current date for output 

timebuf comml4 character*8-current time for output 

dchigh (4000) comml5 high index for each device, into dcomraen 

dclow (4000) comml5 low index for each device, into dcommen 

dcommen (10000) comml5 character*l-one string holding all device comments 

csopact comml6 ptr to op action structure in cs(calc from read-in) 

cspflt comml6 ptr to header in cs of faulter device (read in) 

endbat comml6 1*1 true if at end of batch(calc) 

endrun comml6 1*1 true if at end of run(calc) 

ftitle comml6 fault list title, read by colist, used act6 & schnop 

infltr comml6 index no. of faulter device(read in) 

memadr (30) comml6 memory relocation constants 

msfblk comml6 ptr to ms fault blk(read in) 

msnxfl comml6 ptr to next op to be sched.,init by colist, inc in act6 

ngfcon comml6 no. of gate faults this stack (calc) 

nomems comml6 no. of rom and ram memories with relocation 

nops comml6 no. of ops in batch (calc) 

opsize (15) comml6 no. of words for corresponding op 

pfltcon comml6 ptr to next fault connection (calc) 

timesiz comml6 no. of qml wds to hold time(read in) 

cseiac (21) comml7 cs addr of 1st word of each ei action (read l,calcrest) 

cseial comral7 last possible ei action entry (calculated) 

cseiar comml7 loc in cs of first ei address register (read) 

cseidr comml7 loc in cs of first ei data register! read) 

mseile comml7 last possible ei list entry (calculated) 

mseili comral7 loc in ms of first ei list(read) 

nexinp comml7 actual number of ei sets for this batch(read) 

cseoac (21) comml8 cs addr of 1st word of each eo action(read l,calcrest) 

cseoal comml8 not used 

cseoar comml 8 loc in cs of first eo address register (read) 

cseodr (20) comml8 loc in cs of data register 
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Fortran Parameters & Common Variables, Sorted by Common Label 


Name Dimension Common 
IiBir 


Description 


eofile 

eonwrd 

eorfl 

eorstr 

mseobu 

mseole 

nexoup 

dmask 

csaddr 

csexter 

cstime 

msexter 

xehigh 

xei 

xelink 

xelow 

xew 

cmask 

cstopa 

gnewt 

gnmcon 

gpa 

gpe 

gpevhd 

gpfrhd 

gpmcon 

gpmraas 

gpnewa 

gpnewe 

gsflag 

gstime 

gtime 

cs (0 

cssup 

Is 

lssup 

ms (0 

mssup 

pcslow 

pcsup 

plslow 

pi sup 

pmslow 

pmsup 

ntrace 

xtrace 

nupcho 

upcsms 

upform 

uplocl 

uploc2 

uptitle 


( 20 ) 

( 20 ) 

( 20 ) 

( 20 ) 


(0:17) 


(4000) 

(4000) 

(4000) 

(4000) 

(4000) 

(0:19) 


20000 ) 

(0:31) 

70000) 


(4000) 

(15) 

(15) 

(15) 

(15) 

(15) 


comml8 

comml8 

comml8 

comml8 

comml8 

comml8 

comml8 

cornml9 

comn2 

comm2 

conm2 

comm2 

comm2 

comm2 

comm2 

comm2 

comm2 

comm20 

comm21 

comm21 

comm21 

corara21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm22 

comm22 

comm22 

conan22 

comm22 

comm22 

comm22 

comm22 

comm22 

comm22 

comm22 

comm22 

comm24 

comm24 

comm25 

comm25 

comm25 

coiran25 

comm25 

comm25 


char*40-name for external output file(read) 

no. qml wrds per datum in eo action-use getparm, termrn 

byte-external output reschedule flag(l-on) 

external output start time for rescheduling 

loc in ms of first eo buffer 

not used 

no. of external output sets 

mask for bit 0, 0-1, 0-2, .. .0-17 

qml control store address for matrix 

qml control store address for first external register 

qml control store address for storing time for outputs 

qml main store address for first external register 

index to last external data structure for each device 

1-external complemented , O-not (not needed after init) 

external link word 

index to first external data structure for each device 
qml cs or ms address of external 

mask for bit 0,1,2. . .17, mask for bits 8&9,0(not used) 

cs address of stop action 

time for new event to be scheduled 

number of action control records 

general purpose pointer to action 

general purpose pointer to event 

ptr to head of event list, init by initfe 

ptr to head of free space list, init by initfe 

pointer to action control block 

pointer to master action control register 

pointer to new action 

pointer to newly allocated event 

stop flag( 1-stop) 

user-defined stop time 

current time 

qml control store 

highest cs loc to save on save file 
qml local store 

highest Is loc to save cm save file 
cpl main store 

highest ms loc to save on save file 
parameter-low dimension for control store (0) 
parameter-high dimension for control store (20000) 
parameter-low dimension for local store (0) 
parameter-high dimension for local store (37) 
parameter-low dimension for main store (0) 
parameter-high dimension for main store (70000) 
no. of devices to be traced 

byte-trace flag(0«dont print output changes, 1-do) 
no. of user print choicest output formats) 
user print choice memory type (0-cs, 1-ms, 2-ls) 
cha rac te r *80-use r print choice format incl. () 
user print choice low mem address to output 
user print choice high mem address to output 
character*20-user print choice title to output 
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Fortran Parameters & Common Variables, Sorted by Common Label 

Name Dimension Common Description 

LaEiT 


zfullw (10000) comm26 byte 

nheads comm27 no. of devices to have headers printed 

xheadt (500) comm27 indexes of devices to have headers printed 

nchange comm28 no. of headers that changed this stack 

xchange (4000) comm28 byte- 0 if x didn't change this stack, 1 if did 

xchid (1000) comm28 index nos. of the headers that changed this stack 

checkon comm29 equi valence ( swl, sw( 1 ) ,checkon) 

sw ( 20 ) comm29 

swl comm29 logical-true if prsw(3) and prsw(4) on( check hdrs) 

sw2-sw20 comm29 logical-switches (not used) 

xebit (4000) comm3 bit no. for external (not needed after init) 

xecsms (4000) comm3 type of external (0»cs,l»ms,2«ls) (not needed afterinit) 

xereg (4000) comm3 external register no. (cs,msls) (not needed afterinit) 

divear comm30 divisor for emulator address reg. to right justify 

emask (1:18) comm31 masks for bits 17,17-16,17-15. . .17-0 

adfand comm4 real-denom,avg dyn fanout, calc in pstack,used 

adfcn comm4 real-numerator, avg dyn fanout change, i.e., enequeued 

adfen comm4 real-numerator, avg dyn fanout examined 

as fan comm4 real-average static fanout, set by getdevn 

nstack (2) comm4 number of items in stack i 

s comm4 current stack number (1 or 2) 

savg comm4 real-average number of items on stack 

sbar comm4 non-current stack number (1 if s-2, 2 if s-1) 

smax comm4 maximum number of items on stack 

smin comm4 minimum number of items on stack 

stack (2,500) comm4 current & new stacks holding indices of stack devices 

ingnin comm5 value to assign to output for devices with no inputs 

initfl comm5 initialization flag ( 0-user, l«coraputer ) 

iprclr comm5 print-clear convention flag: O(l-benign) 1( 1-active) 

ntri comm5 number of devices with defined output values 

triang (4000) comm5 indices of all devices with output value defined 

xeval (4000) comm5 external value for device 

xffval (4000) comm5 "PCTLJK" values for flip-flop 

xhead (4000) comm5 pts to 1st entry in conn list(this device is destin.) 

xival (4000) comm5 internal value for device 

xnudef (4000) commS no. of undefined inputs for this device 

xpval (4000) comm5 predefined output value for device 

dconnt (10000) comm6 connection type for internal connection 

dinnum (10000) conm6 index no. of the source device for connect ioni 

dinval (10000) comm6 value on input line coming into device 

drflag (10000) comm6 reversal flag for connection 

dxnext (10000) comm6 ptr to next item in connection list w.same dest device 

xclass (4000) comm8 device class (gate, flip-flop, or tri-state) 

xdis (4000) comm8 disconnected output value for tri-states 

xr (4000) comm8 R value 

xtype (4000) coimnS device type(fiip-flop,and,nand,or,etc. ' 

xu (4000) comm8 U value 

xvalue (4000) comm8 output value for device 

clOOo parameter-constant of 100 (octal) 

clOo parameter-constant of 10 (octal) 

clff parameter-device class for ff (2) 

clgate parameter-device class for gate (1) 
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Fortran Parameters & Common Variables, Sorted by Common Label 

Name Dimension Common Description 

tSBgr 


cits 

cnqbit 

cnull 

connhi 

connlo 

cpdval 

csentl 

ctyc 

ctyd 

ctyen 

ctygts 

ctyj 

ctyk 

ctyl 

ctyp 

ctyt 

divact 

dumtime 

eiasize 

eilsize 

fbsize 

illacl 

illac2 

illinl 

illoutl 

infin 

maxgfl 

maxmem 

maxnei 

maxupch 

mbitO 

mnlbit 

mnword 

mull 

mul2 

mulnbi 

mulnwo 

nthead 

numvops 

opgtype 

oplifg 

oplifm 

opmtype 

opsbat 

ops run 

opstgO 

opstgl 

opstm 

tema71 

tema81 

temb81 

tyand 


parameter-device class for tri-state (3) 
parameter-number of bits in qml word (18) 
parameter-(O) 

parameter-highest valud value for gate types(7) 
parameter-lowest valid value for gates types(l) 
parameter-user output value for computer calculated(9) 
parameter-sentinel of -1 for action 8 
parameter-connection type to flip-flop input c (2) 
parameter-connection type to flip-flop input d (7) 
parameter-connection type to enable line of tri-state 
parameter-connection type to regular gate (0) 
parameter-connection type to flip-flop input j (5) 

parameter-connection type to flip-flop input k (6) 

parameter-connection type to flip-flop input 1 (4) 

parameter-connection type to flip-flop input p (1) 

parameter-connection type to flip-flop input t (3) 

parameter-divisor to righ- justify action code in action(2048) 
parameter-dummy time to insert into stop action 
parameter-max size in cs fo all ei actions(1000 o) 
parameter-max size in ms for all ei lists 
parameter-no. of qml words in ms fault buffer 
parameter-constant for U. of 111. lowest action code(50) 
parameter-constant for U. of 111. highest action code(52) 
parameter-input unit for045-for U. of Illinois use only 
parameter-output unit for040-for U. of Illinois use only 
parameter-inf ini ty( 2147483647-max no. for i*4) 
parameter-max no. of gate faults per single time(30) 
parameter-max. no. of target memories(30) 
parameter-max no. ei sets (20) 

parameter-maximum no. of user print choices (output formats) 

parameter-mask for rightmost bit 0 (1) 

parameter-mask for no. leftover bits in action 

parameter-mask f. #qml wds/targer wd in 1st wd action( '340'o) 

parameter-(17) 

parameter-(l) 

parameter-divisor to right- justify mnlbit (1) 

parameter-divisor to right- justify mnword (32) 

parameter-max no. of devices which can have headers printed 

parameter-number of valid op codes(8) 

parameter-gate fault op typed ) 

parameter-op code for lift gate fault(5) 

parameter-op code for lift memory fault(7) 

parameter-memory fault op type(2) 

parameter-op code for stop batch(l) 

parameter-op code for stop run(2) 

parameter-op code for stick gate at 0(3) 

parameter-op code for stick gate at 1(4) 

parameter-op code for fault memory(6) 

parameter-mask template for action 7, word 1(' 034000' o) 

parameter-template, action 8, word 1, no rescheduling 

parameter-template , action 8, word 1, resched on 

parameter-device type for and gate (1) 
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Fortran Parameters & Common Variables, Sorted by Common Label 

Name Dimension Common De scripti on 

Label 


tyff 

tynand 

tynor 

tynot 

tynxor 

tyor 

tyxor 

uin 

uinO 

uinl 

uinlO 

uin2 

uin3 

uin4 

uin5 

uin6 

uin7 

uin8 

uin9 

uout 

uoutO 

uoutl 

uout 10 

uout2 

uout3 

uout4 

uout5 

uout6 

uout7 

uout8 

uout9 

vophigh 

voplow 


parameter-device type for ff (0) 
parameter-device type for nand gate (2) 
parameter-device type for nor gate (4) 
parameter-device type for not gate (5) 
parameter-device type for nxor gate (7) 
parameter-device type for or gate (3) 
parameter-device type for xor gate (6) 
parameter-input unit for008-matrix(bdxhd2s.dat) 
parameter-input unit for007-device comments (bdxcormn.dat) 
parameter-input unit forOlO-target memories (bdxmems.dat) 
parameter-input unit for025- 

parameter-input unit forOll-user opt ions (bdxopts.dat) 

parameter-input unit for015- 

parame ter- input unit for016- 

parameter-input unit for017- 

parameter-input unit for009- 

parame ter- input unit for022- 

parameter-input unit for023- 

parameter-input unit for024- 

parameter-output unit for014-output file (bdxout.dat) 
parameter-output unit for018- 

parameter-output unit for012-alpha device list (bdsalph.dat) 
parameter-output unit for030- 

parameter-output unit for013-device name list (bdxnam.dat) 

parameter-output unit for019-matrix for qml( bdxmat.dat) 

parameter-output unit for020-binary check ingfile( bdxcheck.dat) 

parameter-output unit for021- 

parameter-output unit for026- 

parameter-output unit for027- 

parameter-output unit for028- 

parameter-output unit for029- 

parameter-highest valid user op code(7) 

parameter-lowest valid user op code(l) 
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Fortran Parameters & Common Variables, Sorted by Variable Name 

Name Dimension Common Description 

Label 


adfand 

adfcn 

adfen 

asfan 

clOOo 

clOo 

checkon 

clff 

clgate 

cits 

cmask (0:19) 

cnqbit 

cnull 

connhi 

connlo 

cpdval 

cs (0:20000) 
csaddr 
cseiac (21) 
cseial 
cseiar 
cseidr 
csentl 


cseoac 

cseoal 

cseoar 

cseodr 

csexter 

csopact 

cspflt 

cssup 

cstime 

cstopa 

ctyc 

ctyd 

ctyen 

ctygts 

ctyj 

ctyk 

ctyl 

ctyp 

ctyt 

datebuf 

dchigh 

dclow 

dcommen 

dconnt 

dinnum 

dinval 

divact 

divear 

dmask 


( 21 ) 

( 20 ) 


(4000) 

(4000) 

( 10000 ) 

( 10000 ) 

( 10000 ) 

( 10000 ) 


(0:17) 


comm4 real-denom,avg dyn fanout, calc in pstack 

conmi4 real-numerator,avg dyn fanout change, i.e., enequeued 

comm4 real-numerator,avg dyn fanout examined 

comm4 real-average static fanout 

parameter-constant of 100 (octal) 

parameter-constant of 10(octal) 

comm29 equivalence ( swl , sw( 1 ) , checkon ) 

parameter-device class for ff (2) 

parameter-device class for gate (1) 

parameter-device class for tri-state (3) 

comm20 mask for bit 0,1,2. . .17, mask for bits 8&9,0(not used) 

parameter-number of bits in qml word (18) 

parameter-(O) 

parameter-highest valud value for gate types(7) 

parameter-lowest valid value for gates types(l) 

parameter-user output value for computer calculated(9) 

comm22 qml control store 

comm2 qml control store address for matrix 

comml7 cs addr of 1st word of each ei action(read l,calcrest) 

comml7 last possible ei action entry (calculated) 

comml7 loc in cs of first ei address register( read) 

comml7 loc in cs of first ei data register ( read) 

parameter-sentinel of -1 for action 8 

comml8 cs addr of 1st word of each eo action (read l,calcrest) 
comml8 not used 

comml8 loc in cs of first eo address register ( read) 
comml8 loc in cs of data register 

comm2 qml control store address for first external register 
comml6 ptr to op action structure in cs(calc from read-in) 
comml6 ptr to header in cs of faulter device (read in) 
comm22 highest cs loc to save on save file 
comm2 qml control store address for storing time for outputs 
comm21 cs address of stop action 
parameter-connection type to flip-flop input c (2) 
parameter-connection type to flip-flop input d (7) 
parameter-connection type to enable line of tri-state 
parameter-connection type to regular gate (0) 
parameter-connection type to flip-flop input j (5) 

parameter-connection type to flip-flop input k (6) 

parameter-connection type to flip-flop input 1 (4) 

parameter-connection type to flip-flop input p (1) 

parameter-connection type to flip-flop input t (3) 

comml4 character*9-current date for output 
comml5 high index for each device, into dcomroen 
comml5 low index for each device, into dcommen 
comml5 character*l-one string holding all device comments 
comm6 connection type for internal connection 
comm6 index no. of the source device for connectioni 
comm6 value on input line coming into device 
parameter-divisor to righ- justify action code in action(2048) 
comm30 divisor for emulator address reg. to right justify 
comml9 mask for bit 0, 0-1, 0-2, .. .0-17 
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Fortran Parameters & Common Variables, Sorted by Variable Name 

Name Dimension Common Description 

Label 


drflag (10000) 
dumtime 

dxnext (10000) 

eiasize 

eilsize 

emask (1:18) 

endbat 

endrun 

eofile (20) 

eonwrd ( 20 ) 

eorfl (20) 

eorstr (20) 

fbsize 

ftitle 

gnewt 

gnmcon 

gpa 

gpe 

gpevhd 

gpfrhd 

gpmcon 

gpmmas 

gpnewa 

gpnewe 

gsflag 

gstime 

gtime 

illacl 

illac2 

illinl 

illoutl 

infin 

infltr 

ingnin 

initfl 

iprclr 

Is (0:31) 

lssup 

maxconn 

maxgate 

maxgfl 

maxraem 

maxnei 

maxupch 

mbitO 

memadr ( 30 ) 

mnlbit 

mnword 

ms (0:70000) 
mseile 
mseili 
mseobu 


comm6 reversal flag for connection 
parameter-dummy time to insert into stop action 
comm6 ptr to next item in connection list w.same dest device 
parameter-max size in cs fo all ei actions(1000 o) 
parameter-max size in ms for all ei lists 
comm31 masks for bits 17,17-16,17-15. . .17-0 
comml6 1*1 true if at end of batch(calc) 
comml6 1*1 true if at end of run(calc) 
comml8 char*40-name for external output filet read) 

no. qml wrds per datum in eo action-use getparm,termrn 
byte-external output reschedule flag(l-on) 
external output start time for rescheduling 
parameter-no. of qml words in ms fault buffer 
comml6 fault list title, read by colist, used act6 & schnop 
time for new event to be scheduled 
number of action control records 
general purpose pointer to action 
general purpose pointer to event 
ptr to head of event list, init by initfe 
ptr to head of free space list, init by initfe 
pointer to action control block 
pointer to master action control register 
pointer to new action 
pointer to newly allocated event 
stop flag (1-stop) 
user-defined stop time 
current time 

parameter-constant for U. of 111. lowest action code(50) 
parameter-constant for U. of 111. highest action code(52) 
parameter-input unit for045-for U. of Illinois use only 
parameter-output unit for040-for U. of Illinois use only 
parameter-infinity( 2147483647-max no. for i*4) 
comml6 index no. of faulter device(read in) 

value to assign to output for devices with no inputs 
initialization flag (0=user,l=computer) 
print-clear convention flag: O(l-benign) l(l-active) 
qml local store 

highest Is loc to save on save file 
parameter-max no. of internal connections allowed 
parameter-max no. of gates allowed 
parameter-max no. of gate faults per single time (30) 
parameter-max. no. of target memories(30) 
parameter-max no. ei sets (20) 

parameter-maximum no. of user print choices (output formats) 
parameter-mask for rightmost bit 0 (1) 
comml6 memory relocation constants 
parameter-mask for no. leftover bits in action 
parameter-mask f. #qml wds/targer wd in 1st wd action( '340'o) 
comm22 qml main store 

comml7 last possible ei list entry ( calculated ) 
comml7 loc in ms of first ei list(read) 
coroml8 loc in ms of first eo buffer 


comml8 

comml8 

comm!8 


comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 

comm21 


comm5 

comm5 

comm5 

comm22 

comm22 
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Fortran Parameters & Common Variables, Sorted by Variable Name 

Name Dimension Common Description 

Label 


mseole 

msexter 

msfblk 

msnxfl 

mssup 

mull 

mul2 

mulnbi 

mulnwo 

nchange 

nconnec 

nexinp 

nexoup 

nextern 

ngates 

ngfcon 

nheads 

nomems 

nops 

nstack ( 2 ) 

nthead 

ntrace 

ntri 

numvops 

nupcho 

opgtype 

oplifg 

oplifm 

opmtype 

opsbat 

opsize (15) 

ops run 

opstgO 

opstgl 

opstm 

pcslow 

pcsup 

pfltcon 

plslow 

pi sup 

pmslow 

pmsup 

prloc (3,2) 
prsw ( 50 ) 

prtime (30) 
prtisw (10) 
runtitle(lO) 
s 

savg 

sbar 

smax 

smin 


comml8 not used 

comm2 qml main store address for first external register 
comml6 ptr to ms fault blk(read in) 

comml6 ptr to next op to be sched.,init by colist, inc in act6 
comm22 highest ms loc to save on save file 
parameter- ( 17 ) 
parameter-(l) 

parameter-divisor to right- justify mnlbit (1) 

parameter-divisor to right- justify mnword (32) 

comm28 no. of headers that changed this stack 

comml no. of connections, set by prep roc 

comml7 actual number of ei sets for this batch(read) 

comml8 no. of external output sets 

comml no. of external connections, set by preproc 

comml no. of devices, set by initrn-neqn 

comml6 no. of gate faults this stack (calc) 

comm27 no. of devices to have headers printed 

comml6 no. of rom and ram memories with relocation 

comml6 no. of ops in batch(calc) 

comm4 number of items in stack i 

parameter-max no. of devices which can have headers printed 

comm24 no. of devices to be traced 

comm5 number of devices with defined output values 

parameter-number of valid op codes(8) 

comm25 no. of user print choices (output formats) 

parameter-gate fault op typed ) 

parameter-op code for lift gate fault(5) 

parameter-op code for lift memory fault(7) 

parameter-memory fault op type(2) 

parameter-op code for stop batch(l) 

comml6 no. of words for corresponding op 

parameter-op code for stop run(2) 

parameter-op code for stick gate at 0(3) 

parameter-op code for stick gate at 1(4) 

parameter-op code for fault memory(6) 

comm22 parameter-low dimension for control store (0) 

comm22 parameter-high dimension for control store (20000) 

comml6 ptr to next fault connection( calc ) 

comm22 parameter-low dimension for local store (0) 

comm22 parameter-high dimension for local store (37) 

comm22 parameter-low dimension for main store (0) 

comm22 parameter-high dimension for main store (70000) 

co8 low & high address for cs,ms,ls for output 

co8 user print option switched, 0-off , l=or 

co8 print window l=start, 2-stop, 3-delta 

co8 1-print window flag(l-on) 

comml title for run, read in getparm from eopts file 

comm4 current stack number (1 or 2) 

comm4 real -average number of items on stack 

comm4 non-current stack number (1 if s-2, 2 if s-1) 

comm4 maximum number of items on stack 

comm4 minimum number of items on stack 
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Name 


Fortran Parameters & Common Variables, Sorted by Variable Name 


Dimension Common 
laBeT 



stack (2,500) comm4 current & new stacks holding indices of stack devices 
sw ( 20 ) comm29 


swl 

sw2-sw20 

tema71 

tema81 

temb81 

timebuf 

timesiz 

title (10) 

triang (4000) 

tyand 

tyff 

tynand 

tynor 

tynot 

tynxor 

tyor 

tyxor 

uin 

uinO 

uinl 

uinlO 

uin2 

uin3 

uin4 

uin5 

uin6 

uin7 

uin8 

uin9 

uout 

uoutO 

uoutl 

uoutlO 

uout2 


comm29 logical-true if prsw(3) and prsw(4) on(check hdrs) 
comm29 logical-switches (not used) 

parameter-mask template for action 7, word K'034000'o) 

parameter-template, action 8, word 1, no rescheduling 

parameter-template, action 8, word 1, resched on 

comml4 characte r*8-cur rent time for output 

comml6 no. of qml wds to hold time (read in) 

comml i*4-title for output, read from opts file by initrn 

coram5 indices of all devices with output value defined 

parameter-device type for and gate (1) 

parameter-device type for ff (0) 

parameter-device type for nand gate (2) 

parameter-device type for nor gate (4) 

parameter-device type for not gate (5) 

parameter-device type for nxor gate (7) 

parameter-device type for or gate (3) 

parameter-device type for xor gate (6) 

parameter-input unit for008-matrix( bdxhd2s.dat) 

parameter-input unit for007-device comments (bdxcomm.dat) 

parameter-input unit forOlO-target memories! bdxmems.dat) 

parameter-input unit for025- 

parameter-input unit forOll-user opt ions ( bdxopts. dat ; 

parameter-input unit for015- 

parameter-input unit for016- 

parame ter- input unit for017- 

parame ter- input unit for009- 

parame ter- input unit for022- 

parameter-input unit for023- 

parameter-input unit for024- 

parameter-output unit for014-output file (bdxout.dat) 
parameter-output unit for018- 

parameter-output unit for012-alpha device list( bdsalph.dat) 
parameter-output unit for030- 

parameter-output unit for013-device name list (bdxnam.dat) 


uout3 parameter-output unit for019-matrix for qml(bdxmat .dat ) 

uout4 parameter-output unit for020-binary checkingfile(bdxcheck dat) 

uout5 parameter-output unit for021- 

uout6 parameter-output unit for026- 

uout7 parameter-output unit for027~ 

uout8 parameter-output unit for028- 

uout9 parameter-output unit for029- 

upcsms (15) comm25 user print choice memory type(0=cs,l=ms,2«ls) 

upforra (15) comm25 characte r*80-user print choice format incl. ( > 

uplocl (15) comm25 user print choice low mem address to output 

uploc2 (15) comm25 user print choice high mem address to output 

uptitle (15) comm25 character*20-user print choice title to output 
vophigh parameter-highest valid user op code(7) 

voplow parameter- lowest valid user op code(l) 

xaddres (4000) comml qml control store address for header for device i 

xchange (4000) comm28 byte- 0 if x didn't change this stack, 1 if did 
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Fortran Parameters & Common Variables, Sorted by Variable Name 


Name Dimension Common 
Label 


Description 


xchid 

(1000) 

comm28 

xclass 

(4000) 

comm8 

xconn 

(10000) 

comml 

xcount 

(4000) 

commll 

xdis 

(4000) 

commS 

xebit 

(4000) 

comm3 

xecsms 

(4000) 

comm3 

xehigh 

(4000) 

comm2 

xei 

(4000) 

comm2 

xelink 

(4000) 

comm2 

xelow 

(4000) 

comm2 

xereg 

(4000) 

comm3 

xeval 

(4000) 

comm5 

xew 

(4000) 

comm2 

xffval 

(4000) 

comm5 

xhdr 

(4000) 

comml 

xhead 

(4000) 

comm5 

xheadt 

(500) 

comm27 

xhigh 

(4000) 

comml 

xival 

(4000) 

comm5 

xlink 

(10000) 

comml 

xlow 

(4000) 

comml 

xname 

(4000) 

co6 

xnudef 

(4000) 

comm5 

xpval 

(4000) 

comm5 

xr 

(4000) 

comm8 

xstack 

(4000) 

commll 

xtrace 

(4000) 

comm24 

xtype 

(4000) 

comm8 

XU 

(4000) 

comm8 

xvalue 

(4000) 

comm8 

zfullw 

(10000) 

comra26 

zptr 

(10000) 

comml 


index nos. of the headers that changed this stack 

device class ( gate, flip-flop, or tri-state) 

full address for internal connection 

initial value of "count" for each device 

disconnected output value for tri-states 

bit no. for external (not needed after init) 

type of external ( 0=cs , l«ms , 2-1 s ) ( not needed afterinit) 

index to last external data structure for each device 

1-external complemented , 0-not (not needed after init) 

external link word 

index to first external data structure for each device 

external register no. (cs,msls) (not needed afterinit) 

external value for device 

qml cs or ms address of external 

"PCTLJK" values for flip-flop 

header for each device i 

pts to 1st entry in conn list(this device is destin.) 

indexes of devices to have headers printed 

index to connection list for last conn for device i 

internal value for device 

first word of internal connector record 

index to connection list for first conn for device i 

character *20-device names, set by getdevn 

no. of undefined inputs for this device 

predefined output value for device 

R value 

stack flag for device( 0-not on,l-is on 1st stack) 
byte-trace flag(0-dont print output changes, 1-do) 
device type( f i ip-flop, and, nand, or, etc. ) 

U value 

output value for device 
byte 

the index of the dest device for this connection 
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Note: Any case not in table represents no action taken, and branch to "Skip". 
For input columns, blanks are "don't care" conditions. 

1 Check whether device should be enqueued, and continue processing. 

2 Skip enqueueing check, and just continue processing. 































































QM-1 Emulator Files 


File 

Operating 

File 

File Description 

Name System 

Nanocode Bnulator: 


BBEMPlVl : S 

Nova 

Source 

Emulator Nanocode, Part 1 

BBEMPlVl 

Nova 

Binary 

It 

BBBNBIN 

Nova 

Definition " 

BBEMP2V1 : S 

Nova 

Source 

Emulator Nanocode, Part 2 

BBEMP2V1 

Nova 

Binary 

It 

BBEMP3V1 : S 

Nova 

Source 

Emulator Nanocode, Part 3 

BBEMP3V1 

Nova 

Binary 

If 

MSNANON:S 

Nova 

Source 

Main Store Extend. Address. Nanoword 

BBNANOErS 

Easy 

Source 

It 

MSNANONrB 

Nova 

Binary 

It 

MSNANONrM 
Microcode Driver 

Nova 

' m 
• 

Mapped 

It 

BBDSNOVArS 

Nova 

Source 

Symbol Definitions 

BBDSEASY : S 

Easy 

Source 

II 

BBGDNOVA:S 

Nova 

Source 

Global Data Definitions 

BBGDEASY : S 

Easy 

Source 

It 

BBGD:B 

Nova 

Binary 

II 

BBDRNOVA:S 

Nova 

Source 

Driver Module 

BBDREASY : S 

Easy 

Source 

It 

BBDR:B 

Nova 

Binary 

It 

BBAlNOVArS 

Nova 

Source 

Action Modules Set 1 

BBAlEASY : S 

Easy 

Source 

II 

BBAl :B 

Nova 

Binary 

II 

BBA2EASY : S 

Easy 

Source 

II 

BBA2:B 

Nova 

Binary 

II 

BBESNOVAjS 

Nova 

Source 

Subroutine Modules Set 1 

BBESEASY : S 

Easy 

Source 

It 

BBES : B 

Nova 

Binary 

II 

BBEMNOVArS 

Nova 

Source 

Subroutine Modules Set 2 

BBEMEASY : S 

Easy 

Source 

ll 

BBEM:B 

Nova 

Binary 

It 

BBEENOVArS 

Nova 

Source 

Subroutine Modules Set 3 

BBEE : B 

Nova 

Binary 

II 

BBUTNOVArS 

Nova 

Source 

Utility Modules for Driver 

BBUTEASY : S 

Easy 

Source 

II 

BBUTrB 

Nova 

Binary 

II 

BBIONOVA:S 

Nova 

Source 

I/O Modules for Driver 

BBIOEASY : S 

Easy 

Source 

It 

BBIO:B 

Nova 

Binary 

II 

BBECOMPILE 

Nova 

Execute 

Assemble all Driver Microcode Programs 

BBECONVERT 

Easy 

Execute 

Convert all Driver Source Microcode 
Programs from Easy to Nova 

BBCGD 

Nova 

Execute 

Assemble BBGDNOVA:S 

BBCDR 

Nova 

Execute 

Assemble BBDRNOVArS 

BBCAl 

Nova 

Execute 

Assemble BBA1N0VA:S 

BBCA2 

Nova 

Execute 

Assemble BBA2N0VA:S 

BBCES 

Nova 

Execute 

Assemble BBESNOVA:S 

BBCEM 

Nova 

Execute 

Assemble BBEMNOVA:S 

BBCEE 

Nova 

Execute 

Assemble BBEENOVA:S 

BBCUT 

Nova 

Execute 

Assemble BBUTNOVArS 

BBCIO 

Nova 

Execute 

Assemble BBICNOVA:S 
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QM-1 Utility Files 


File 

Operating 

File 

File Description 

Name 

System 

Type 

EOTODISK 

Easy 

Execute 

Write External Outputs from 
Memory to Disk 

TVAXQMl 

Easy 

Execute 

Transfer Disk File from Vax 
to QMl 

Test VAXQM1 BBVAXQMl 

TQMlVAXI 

Easy 

Execute 

Transfer Disk File from QMl 
to Vax 

Test MV BBMV 

*:E 

Nova 

Execute 

Generate Executable File 
for Target Machine * 

R* 

Nova 

Loadable 

Executable file for Target 
Machine * 

WXMDISKrS 

Easy 

Source 

Write External Outputs from 
Memory to Disk 

WXMDISKrB 

Easy 

Binary 

II 
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File 

Name 


QM-1 Files for Transfers With Vax 


Operating File File Description 

System Type 


Vax to QMl and QMl to vax 


BBGETPIO 

Easy 

Source 

BBFUTPIO 

Easy 

Source 

BBRACKNAK 

Easy 

Source 

BBCACKNAK 

Easy 

Source 

BBVAXIN 

Easy 

Source 

BBREST 

Easy 

Source 

BBVAXOUT 

Easy 

Source 

BBSACKNAK 

Easy 

Source 



QMl to Vax 

BBIVAXIN 

Easy 

Source 

BBACWRTRAN 

Easy 

Source 

BBRDATAF 

Easy 

Source 

BBEXITARUN 

Easy 

Source 

BBIVAXOUT 

Easy 

Source 

BBACCOMPAR 

Easy 

Source 

BBIPUTPIO 

Easy 

Source 

BBIGETPIO 

Easy 

Source 

BBRINTF 

Easy 

Source 

BBMVMAIN : S 

Easy 

Source 

BBMV 

Easy 

Executable 

BBMVSEM):S 

Easy 

Source 

TQMlVAXI 

Easy 

Execute 



Vax to QMl 

BBPVAXQM1 

Easy 

Source 

BBVAXQM1 

Easy 

Executable 

BBWRDATAF 

Easy 

Source 

BBWRTRANF 

Easy 

Source 

BBEXITRUN 

Easy 

Source 

TVAXQMl 

Easy 

Execute 


Get next record from pio interface 
i.e. f wait till ready, and 
determine no. of records read 
Put next record out over pio interface 
Receive acknowledge/no ack. code 
Calculate whether ack or nak code recvd 
Get next record from pio( lowest level) 
Miscellaneous low-level modules for 
interface 

Put next record to pio( lowest level) 
from a character array 
Send ack/nak code over pio 


Get next record from pio( lowest level) 
(as an integer array) 

Write activity on transaction log file 
Read next record from QMl disk file 
Close disk files and exit the run 
Put next record to pio( lowest level) 
from an integer array 
Compare record sent to record received 
Put next record out over pio, from 
an integer array 

Get next record from pio interface 
(as an integer array) 

Read next integer value from QMl 
disk file 
Main Program 
Main Program 

Send record from QMl to Vax 
Transfer disk file from QMl to Vax 


Main Program 
Main Program 

Write record received to QMl disk file 
Write activity on transaction log file 
Close disk files and exit the run 
Transfer disk file from Vax to QMl 
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External Connections Flag 0-the output of this device 

does not feed into any 
external registers 
l*the output of this device 
feeds into one or more 


Legends for Header Words 
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Appendix C 

Sample Netlist File 



Sample Netlist File 


> FPTS X F 0 0 

0 

CLASS= 

1 

TYPE * 

5 

VALUE* 

9 

NI CON* 

X 

NECON* 

0 

F PTS 1 FO 0 

0 

ZNAME* 


TS1G20 




REVER* 

0 

CONNT* 

0 

>FPTSlF01 

0 

CLAS5= 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

2 

NECON* 

0 

FPTS 1 F 0 1 

0 

2 N AM E = 


TS XGO 3 




REVER* 

0 

CONNT* 

0 

F PTS 1 F 0 1 

0 

Z NAME = 


TS 1G0 6 




REVER* 

0 

CONNT* 

0 

> FPTS1FO 2 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

F PTS 1 F 0 2 

0 

ZNAME* 


TS 1GO 2 




REVER* 

0 

CONNT* 

0 

> FPTS 1 FO 3 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

2 

NECON* 

0 

FPTS 1 FO 3 

0 

ZNAME* 


TS2G4 3 




REVER* 

X 

CONNT* 

0 

FPTS1F03 

0 

ZN AME = 


TS 1G2 0 




REVER* 

0 

CONNT* 

0 

> F PTS 1 FO 4 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

2 

NECON* 

0 

FPTS 1 F 0 4 

0 

Z N AME = 


TS2G4 5 




REVER* 

1 

CONNT* 

0 

FPTS 1 F 0 4 

0 

ZNAME* 


TS 1G 2 0 




REVER* 

0 

CONNT* 

0 

>FPTSlF05 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

2 

NECON* 

0 

FPTS1F05 

0 

ZNAME* 


TS 2G0 4 




REVER* 

1 

CONNT* 

0 

FPTS1F05 

0 

ZNAME* 


TS 1 FO 0 




REVER* 

0 

CONNT* 

-3 

> F PTS 1 F 0 6 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

F PTS 1 FO 6 

0 

ZNAME* 


TS 1G2 0 




REVER* 

0 

CONNT* 

0 

> FPTS 1 FO 7 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

F PTS 1 F 0 7 

0 

ZNAME* 


TS 1G2 0 




REVER* 

0 

CONNT* 

0 

> FPTS 2F0 0 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

FPTS2F00 

0 

ZNAME* 


TS2G09 




REVER* 

0 

CONNT* 

0 

FPTS 2 FO 0 

0 

ZNAME* 


TS2G10 




REVER* 

0 

CONNT* 

0 

FPTS2FOO 

0 

ZNAME* 


TS2G1 1 




REVER* 

0 

CONNT* 

0 

> FPTS2F01 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

FPTS2F01 

0 

ZNAME* 


TS 2G 1 4 




REVER* 

0 

CONNT* 

0 

FPTS 2F0 1 

0 

ZNAME* 


TS 2G1 0 




REVER* 

0 

CONNT* 

0 

FPTS 2 F 0 1 

0 

ZNAME* 


TS2G12 




REVER* 

0 

CONNT* 

0 

> FPTS 2 F 0 2 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

FPTS 2F0 2 

0 

ZNAME* 


TS2G1 3 




REVER* 

0 

CONNT* 

0 

FPTS 2 F 0 2 

0 

ZNAME* 


TS 2G0 9 




REVER* 

0 

CONNT* 

0 

F PTS 2 F 0 2 

0 

ZNAME* 


TS 2G 1 2 




REVER* 

0 

CONNT* 

0 

> FPTS 2 FO 3 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

FPTS2F03 

0 

ZNAME* 


TS2G14 




REVER* 

0 

CONNT* 

0 

F PTS 2 FO 3 

0 

ZNAME* 


TS2G1 3 




REVER* 

0 

CONNT* 

0 

FPTS 2 FO 3 

0 

ZNAME* 


TS 2G 1 1 




REVER* 

0 

CONNT* 

0 

> FPTS 2 F 0 4 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

FPTS2F04 

0 

ZNAME* 


TS 2G1 9 




REVER* 

0 

CONNT* 

0 

FPTS 2 F 0 4 

0 

ZNAME* 


TS2GX8 




REVER* 

0 

CONNT* 

0 

FPTS 2 F 0 4 

0 

ZNAME* 


TS 2G X 7 




REVER* 

0 

CONNT* 

0 

> F PTS 2 F 0 5 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

Q 

FPTS 2 F 0 5 

0 

ZNAME* 


TS 2G2 2 




REVER* 

0 

CONNT* 

0 

FPTS 2F0 5 

0 

ZNAME* 


TS2G 2 0 




REVER* 

0 

CONNT* 

0 

FPTS 2 F 0 5 

0 

ZNAME* 


TS 2G X 8 




REVER* 

0 

CONNT* 

0 

> FPTS2F06 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

F PTS 2 F 0 6 

0 

ZNAME* 


TS 2G2 X 




REVER* 

0 

CONNT* 

0 

F PTS 2 F 0 6 

0 

ZNAME* 


TS 2G 2 0 




REVER* 

0 

CONNT* 

0 

FPTS 2 FO 6 

0 

ZNAME* 


TS 2G1 7 




REVER* 

0 

CONNT* 

0 

> FPTS 2 F 0 7 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

FPTS 2 F 0 7 

0 

ZNAME* 


T .S 2 G 2 2 




REVER* 

0 

CONNT* 

0 

FPTS2F07 

0 

ZNAME* 


TS2G2X 




REVER* 

0 

CONNT* 

0 

F PTS 2 FO 7 

0 

ZNAME* 


TS 2GX 9 




REVER* 

0 

CONNT* 

0 

> FPTS 2 FO 8 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 


c - 1 


F PTS 2 F 0 8 

0 

Z N AM E * 


TS2G44 




REVER* 

0 

CONNT* 

0 

> FPTS2F09 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NI CON* 

X 

NECON* 

0 

F V T S 2 F 0 9 

0 

ZNAME* 


TS2G44 




REVER* 

0 

CONNT* 

0 

> FPTS 2 F 1 0 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

FPTS2F1 0 

0 

ZNAME* 


TS2G44 




REVER* 

0 

CONNT* 

0 

> TS 1 F 0 0 

0 

CLASS* 

2 

TYPE = 

0 

VALUE* 

9 

NICON* 

X 

NECON* 

2 

TS 1 F 0 0 

0 

FFVAL= 

7 2 









TS 1 F 0 0 

0 

R 

0 

U 

0 







TS 1 FOO 

0 

Z N AME = 


FPTS1F00 




REVER* 

1 

CONNT* 

0 

TS 1 F 0 0 

0 

CSMSF* 

0 

REGNO* 

4 

BITNO* 

X 2 

REVER* 

0 



TS 1 F 0 0 

0 

C S MS F = 

0 

REGNO* 

6 

B I T NO* 

2 

REVER* 

0 



> TS 1 FO 1 

0 

CLASS* 

2 

TYPE = 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS1F01 

0 

FFVAL* 

72 









TS 1 F 0 X 

0 

R = 

0 

U * 

0 







TS 1 F 0 1 

0 

Z NAME * 


FPTSXFOX 




REVER* 

1 

CONNT* 

0 

TS1F01 

0 

CSMSF* 

0 

REGNO* 

4 

BITNO* 

I X 

REVER* 

0 



> TS 1 FO 2 

0 

CLASS* 

2 

TYPE = 

0 

VALUE* 

X 

NICON* 

1 

NECON* 

1 

TS1F02 

0 

F FVAL = 

72 









TS 1 F 0 2 

0 

R 

0 

U 

0 







T S X F 0 2 

0 

ZNAME* 


FPTSXF02 




REVER* 

1 

CONNT* 

0 

TS 1 FO 2 

0 

CSMSF* 

0 

REGNO* 

5 

BITNO* 

17 

REVER* 

0 



> TS X FO 3 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS X FO 3 

0 

FFVAL* 

72 









TS X FO 3 

0 

R 

0 

u 

0 







TSXF03 

0 

Z NAME * 


FPTSXF03 




REVER* 

1 

CONNT* 

0 

TSXF03 

0 

CSMSF = 

0 

REGNO* 

5 

BITNO* 

16 

REVER* 

0 



> T S X F 0 4 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON- 

1 

TSX FO 4 

0 

FFVAL* 

72 









TS X F 0 4 

0 

R 

0 

U 

0 







TS X FO 4 

0 

ZNAME* 


FPTSXF04 




REVER* 

1 

CONNT* 

0 

TS X FO 4 

0 

CSMSF* 

0 

REGNO* 

5 

BITNO* 

X 5 

REVER* 

0 



> TS 1 FO 5 

0 

CLASS* 

2 

TYPE = 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TSXF05 

0 

FFVAL* 

7 2 









TSXF05 

0 

R 

0 

U 

0 







TS X F 0 5 

0 

ZNAME* 


FPTSXF05 




REVER* 

1 

CONNT* 

0 

; TS1F05 

0 

CSMSF* 

0 

REGNO* 

5 

BITNO* 

14 

REVER* 

0 



! > TS1 F06 

0 

CLASS* 

2 

TYPE = 

0 

VALUE* 

1 

NICON* 

1 

NECON* 

2 

TSXF06 

0 

FFVAL* 

72 









TS1F06 

0 

R 

0 

U 

0 







TS 1 F 0 6 

0 

ZNAME* 


FPTSXF06 




REVER* 

1 

CONNT* 

0 

TS X F 0 6 

0 

CSMSF* 

0 

REGNO* 

5 

BITNO* 

1 3 

REVER* 

0 



1 TS 1 F 0 6 

0 

CSMSF* 

0 

REGNO* 

6 

BITNO* 

1 

REVER* 

0 



> T S 1 F 0 7 

0 

CLASS* 

2 

TYPE = 

0 

VALUE* 

1 

NICON* 

1 

NECON* 

2 

TSXF07 

0 

FFVAL* 

72 









TS X F 0 7 

0 

R 

0 

U 

0 







TSXF07 

0 

ZNAME* 


FPTSXF07 




REVER* 

X 

CONNT* 

0 

TS X F 0 7 

0 

CSMSF* 

0 

REGNO* 

5 

BITNO* 

1 2 

REVER* 

0 



TS 1 F 0 7 

0 

CSMSF* 

0 

REGNO* 

6 

BITNO* 

0 

REVER* 

0 



> T S X G 0 0 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS1G00 

0 

ZNAME* 


TSXFOO 




REVER* 

0 

CONNT* 

7 

TS X G 0 0 

0 

CSMSF* 

0 

REGNO* 

4 

BITNO* 

17 

REVER* 

0 



> TS 1 G 0 X 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TSIGOX 

0 

ZNAME* 


TSXGO 2 




REVER* 

0 

CONNT* 

0 

' T S 1 G 0 1 

0 

CSMSF* 

0 

REGNO* 

4 

BITNO* 

16 

REVER* 

0 



1 > T S X G 0 2 

0 

CLASS* 

1 

TYPE = 

1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 


C - 2 



TS 1G0 2 

0 

ZNAME= 


TS1F01 




REVER* 

0 

CONNT- 

7 

> TS 1GO 3 

0 

CLASS* 

1 

TYPE. = 

5 

VALUE* 

9 

NI CON* 

1 

NECON* 

0 

TS1G03 

0 

Z NAME = 


TS1G04 




REVER* 

0 

CONNT* 

0 

>TS1G04 

0 

CLASS- 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS1G04 

0 

ZNAME= 


TS1G05 




REVER* 

0 

CONNT* 

0 

> TS 1GO 5 

0 

CLAS S= 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS1G05 

0 

ZNAME- 


TS1G06 




REVER* 

0 

CONNT- 

0 

> T S 1 G 0 6 

0 

CLASS= 

1 

TYPE = 

1 

VALUE* 

9 

NICON* 

6 

NECON* 

1 

TS1G06 

0 

ZNAME— 


TS1F07 




REVER* 

0 

CONNT- 

2 

TS1G06 

0 

ZNAME* 


TS1F06 




REVER* 

0 

CONNT* 

2 

TS1G06 

0 

Z N AME - 


TS1F05 




REVER* 

0 

CONNT* 

2 

TS1G06 

0 

Z NAME* 


TS1F04 




REVER* 

0 

CONNT* 

2 

TS1G06 

0 

ZNAME- 


TS1F03 




REVER- 

0 

CONNT* 

2 

TS1G06 

0 

Z NAME® 


TS1P02 




REVER* 

0 

CONNT* 

2 

TS1G06 

0 

CSMSF- 

0 

REGNO* 

4 

BITNO* 

15 

REVER- 

0 



> T S 1 G 0 7 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

1 

NICON* 

1 

NECON* 

0 

TS1G07 

0 

Z NAME * 


TS1G0 8 




REVER* 

0 

CONNT* 

0 

> T S 1 G 0 8 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS1G08 

0 

ZNAME* 


TS1G09 




REVER* 

0 

CONNT* 

0 

> T S 1 G 0 9 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON— 

1 

NECON* 

0 

TS1G09 

0 

Z NAME * 


TS1G10 




REVER* 

0 

CONNT* 

0 

> TS1G1 0 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON- 

1 

NECON* 

0 

TS1G1 0 

0 

ZNAME* 


TSlGl 1 




REVER- 

0 

CONNT* 

0 

> T S 1 G 1 1 

0 

CLASS* 

1 

TYPE * 

5 

VALUE- 

9 

N I CON— 

1 

NECON* 

0 

TSlGl 1 

0 

ZNAME- 


TSlGl 2 




REVER* 

0 

CONNT* 

0 

> T S 1 G 1 2 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS1G1 2 

0 

Z NAME* 


TSlGl 3 




REVER* 

0 

CONNT* 

0 

> TS 1 G 1 3 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

9 

NECON* 

0 

TSlGl 3 

0 

ZNAME* 


TS 1 GO 7 




REVER* 

0 

CONNT* 

0 

TSlGl 3 

0 

ZNAME* 


TS1F01 




REVER- 

0 

CONNT* 

-3 

TS1G1 3 

0 

ZNAME* 


TS1F07 




REVER* 

0 

CONNT* 

- 3 

TSlGl 3 

0 

ZNAME* 


TS1F06 




REVER* 

0 

CONNT* 

-3 

TSlGl 3 

0 

ZNAME* 


TS1F05 




REVER* 

0 

CONNT* 

-3 

TSlGl 3 

0 

ZNAME* 


TS1F04 




REVER- 

0 

CONNT* 

-3 

TSlGl 3 

0 

ZNAME* 


TS1F03 




REVER* 

0 

CONNT* 

— 3 

TS1G13 

0 

ZNAME* 


TS1F02 




REVER- 

0 

CONNT* 

-3 

TSlGl 3 

0 

ZNAME* 


TS1G21 




REVER* 

0 

CONNT* 

0 

> TS 1 G 1 4 

0 

CL ASS* 

1 

TYPE * 

3 

VALUE* 

1 

NICON* 

1 

NECON* 

1 

TS1G14 

0 

ZNAME* 


TS 1 F 0 2 




REVER* 

0 

CONNT* 

7 

TSlGl 4 

0 

CSMSF* 

0 

REGNO* 

4 

BITNO* 

14 

REVER* 

0 



> T S 1 G 1 5 

0 

CLASS* 

1 

TYPE = 

3 

VALUE- 

0 

NICON* 

1 

NECON* 

0 

TS1G15 

0 

ZNAME* 


TS 1 FO 3 




REVER* 

0 

CONNT* 

7 

> T S 1 G 1 6 

0 

CLASS* 

1 

TYPE * 

3 

VALUE* 

0 

NICON— 

1 

NECON* 

0 

TSlGl 6 

0 

ZNAME* 


TS1F04 




REVER* 

0 

CONNT* 

7 

> T S 1 G 1 7 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

0 

NICON* 

1 

NECON- 

1 

TS1G17 

0 

ZNAME* 


TS1F05 




REVER* 

0 

CONNT* 

7 

TSlGl 7 

0 

CSMSF* 

0 

REGNO* 

4 

BITNO* 

1 3 

REVER* 

0 



> T S 1 G 1 8 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

1 

NICON* 

1 

NECON* 

0 

TS1G18 

0 

ZNAME* 


TS1F06 




REVER* 

0 

CONNT* 

7 

> T S 1 G 1 9 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

1 

NICON* 

1 

NECON* 

0 

TS1G19 

0 

ZNAME* 


TS 1 FO 7 




REVER* 

0 

CONNT* 

7 

> T S 1 G 2 0 

0 

CLASS* 

1 

TYPE * 

3 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS1G20 

0 

ZNAME* 


TS1G20 




REVER* 

0 

CONNT* 

0 

> T S 1 G 2 1 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS1G21 

0 

ZNAME* 


TS1G2 2 




REVER* 

0 

CONNT- 

0 


C - 3 


> TS 1 G 2 2 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON- 

0 

TS 1 G 2 2 

0 

Z NAME * 


TS1G23 




REVER* 

0 

CONNT * 

0 

> TS 1 G 2 3 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

2 

NECON* 

2 

TS1G23 

0 

ZNAME* 


TS1G2 4 




REVER* 

0 

CONNT* 

0 

TS1G23 

0 

Z NAME * 


TS1G25 




REVER* 

0 

CONNT* 

0 

TS1G23 

0 

CSMSF* 

0 

REGNO=280 

BITNO* 

17 

REVER* 

0 



TS1G23 

0 

CSMSF* 

0 

REGNO*281 

BITNO* 

15 

REVER* 

0 



> T S 1 G 2 4 

0 

CLASS* 

1 

TYPE * 

1 

VALUE* 

1 

NICON* 

1 

NECON* 

0 

TS1G24 

0 

ZNAME* 


TS1G2 4 




REVER* 

0 

CONNT* 

0 

> T S 1 G 2 5 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS1G25 

0 

Z NAME * 


TS1G26 




REVER* 

0 

CONNT* 

0 

> T S 1 G 2 6 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

3 

TS1G26 

0 

ZNAME* 


TS1G27 




REVER* 

0 

CONNT* 

0 

TS1G26 

0 

CSMSF* 

0 

REGNO* 2 8 0 

BITNO* 

17 

REVER* 

0 



TS1G26 

0 

CSMSF* 

0 

REGNO* 2 8 1 

BITNO* 

17 

REVER* 

0 



TS1G26 

0 

CSMSF* 

0 

REGNO* 2 81 

BITNO* 

1 6 

REVER* 

0 



> T S 1 G 2 7 

0 

CLASS* 

1 

TYPE * 

1 

VALUE* 

1 

NICON* 

1 

NECON* 

0 

TS1G27 

0 

ZNAME* 


TS1G27 




REVER* 

0 

CONNT* 

0 

> T S 2 F 0 0 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON- 

0 

TS2FOO 

0 

FFVAL* 

72 









TS2F00 

0 

R 

0 

U * 

0 







TS2F00 

0 

ZNAME* 


FPTS2F00 



REVER* 

1 

CONNT* 

0 

> T S 2 F 0 1 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS2F01 

0 

FF VAL* 

72 









TS2F01 

0 

R 

0 

U * 

0 







TS2F01 

0 

ZNAME* 


FPTS2F01 




REVER* 

1 

CONNT* 

0 

> T S 2 F 0 2 

0 

CLASS* 

2 

TYPE * 

0 

VALUE- 

9 

NICON* 

1 

NECON* 

0 

TS2F02 

0 

FFVAL* 

72 









TS2F02 

0 

R 

0 

U 

0 







TS2F0 2 

0 

ZNAME* 


FPTS2F02 




REVER* 

1 

CONNT* 

0 

> T S 2 F 0 3 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS2F03 

0 

FFVAL* 

72 









TS2F03 

0 

R 

0 

U 

0 







TS 2F0 3 

0 

ZNAME* 


FPTS2F03 




REVER* 

1 

CONNT* 

0 

> T S 2 F 0 4 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS2F04 

0 

FFVAL* 

72 









TS2F04 

0 

R 

0 

U 

0 







TS2F04 

0 

ZNAME* 


FPTS2F04 




REVER* 

1 

CONNT* 

0 

> T S 2 F 0 5 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2F0 5 

0 

FFVAL* 

72 









TS2F05 

0 

R 

0 

U 

0 







TS2F05 

0 

ZNAME* 


FPTS2F05 




REVER* 

1 

CONNT- 

0 

> T S 2 F 0 6 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS2F06 

0 

FFVAL* 

72 









TS2F06 

0 

R * 

0 

U 

0 







TS2F06 

0 

ZNAME* 


FPTS2F06 




REVER* 

1 

CONNT* 

0 

> T S 2 F 0 7 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2 FO 7 

0 

FFVAL* 

72 









TS2F07 

0 

R * 

0 

U 

0 







TS2F07 

0 

ZNAME* 


FPTS2F07 




REVER* 

1 

CONNT- 

0 

> TS 2 F 0 8 

0 

CLASS* 

2 

TYPE * 

0 

VALUE* 

Q 

NICON* 

1 

NECON- 

1 

TS2F08 

0 

FFVAL* 

72 









TS 2 F 0 8 

0 

R 

0 

V 

0 







TS2F08 

0 

ZNAME* 


FPTS2F08 




REVER* 

1 

CONNT* 

0 

TS2F08 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

4 

REVER* 

0 
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0 

r r.A ss* 
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TYPE * 
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VALUE* 

0 
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1 
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1 

rtwr o •» 

0 
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V 
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u 

0 







TS 2 F 0 9 

0 

ZNAME= 


FPTS2F09 




REVER* 

1 

CONNT* 

0 

TS 2 F 0 9 

0 

CSMSF= 

0 

REGNO* 

7 

B I T N 0 = 

5 

REVER* 

0 



> TS 2 F 1 0 

0 

C L AS S = 

2 

TYPE * 
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VALUE* 

0 

NICON* 

1 

NECON* 

1 

TS 2 F 1 0 

0 

F F V A L = 

72 









TS2F10 

0 
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0 
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0 







TS2F10 

0 

Z N AM E = 


FPTS 2 F 1 0 




REVER* 

1 

CONNT* 

0 

TS 2 F 1 0 

0 

CSMSF- 

0 

REGNO* 

7 

B I T NO = 

6 

REVER* 

0 



> T S 2 G 0 0 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

4 

NECON* 

1 

TS2G00 

0 

Z N AME = 


TS2G27 




REVER* 

0 

CONNT* 

0 

TS2G00 

0 

Z N AME = 


TS2G35 




REVER* 

0 

CONNT* 

0 

TS2G00 

0 

Z N AME = 


TS 2G 3 9 




REVER* 

0 

CONNT* 

0 

TS 2G0 0 

0 

Z NAME* 


TS 2 FO 0 




REVER* 

0 

CONNT* 

7 

TS2G00 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

7 

REVER* 

0 



> TS 2G0 1 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS 2G0 1 

0 

Z NAME* 


TS2F01 




REVER* 

0 

CONNT* 

7 

TS 2G0 1 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

8 

REVER* 

0 



> TS 2G0 2 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS 2G0 2 

0 

ZNAME* 


TS2F02 




REVER* 

0 

CONNT* 

7 

TS2G0 2 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

9 

REVER* 

0 



> TS 2 G 0 3 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS2G03 

0 

ZNAME* 


TS 2 FO 3 




REVER* 

0 

CONNT* 

7 

TS 2G 0 3 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

1 0 

REVER* 

0 



> T S 2 G 0 4 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

8 

NECON* 

1 

TS 2G0 4 

0 

ZNAME* 


TS 2 F 0 0 




REVER* 

0 

CONNT* 

-3 

TS 2G 0 4 

0 

ZNAME* 


TS2F0 1 




REVER* 

0 

CONNT* 

-3 

TS 2G0 4 

0 

ZNAME* 


TS2F0 2 




REVER* 

0 

CONNT* 

-3 

TS 2 GO 4 

0 

ZNAME* 


TS2F03 




REVER* 

0 

CONNT* 

-3 

TS 2G0 4 

0 

ZNAME* 


TS2F04 




REVER* 

0 

CONNT* 

-3 

TS2G04 

0 

ZNAME* 


TS2F05 




REVER* 

0 

CONNT* 

-3 

TS 2G0 4 

0 

ZNAME* 


TS2F06 




REVER* 

0 

CONNT* 

-3 

TS 2 G 0 4 

0 

ZNAME* 


TS2F07 




REVER* 

0 

CONNT* 

-3 

TS 2 G 0 4 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

1 1 

REVER* 

0 



> TS 2 G 0 5 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

4 

NECON* 

1 

TS 2 G 0 5 

0 

ZNAME* 


TS2G3 1 




REVER* 

0 

CONNT* 

0 

TS 2G0 5 

0 

ZNAME* 


T S 2 G 3 3 




REVER* 

0 

CONNT* 

0 

TS 2G0 5 

0 

ZNAME* 


TS2G37 




REVER* 

0 

CONNT* 

0 

TS 2 G 0 5 

0 

ZNAME* 


TS 2 F 0 4 




REVER* 

0 

CONNT* 

7 

TS2G0 5 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

1 2 

REVER* 

0 



> TS 2 G 0 6 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS2G06 

0 

ZNAME* 


TS 2F0 5 




REVER* 

0 

CONNT* 

7 

TS2G06 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

1 3 

REVER* 

0 



> TS 2G0 7 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS 2G0 7 

0 

ZNAME* 


TS2F06 




REVER* 

0 

CONNT* 

7 

TS 2G0 7 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

14 

REVER* 

0 



> TS 2 G 0 8 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

1 

NECON* 

1 

TS 2 G 0 8 

0 

ZNAME* 


TS 2 F 0 7 




REVER* 

0 

CONNT* 

7 

TS 2G0 8 

0 

CSMSF* 

0 

REGNO* 

7 

BITNO* 

1 5 

REVER* 

0 



> TS 2G0 9 

0 

CLASS* 

1 

TYPE = 

1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 0 9 

0 

ZNAME* 


TS 2G 1 5 




REVER* 

0 

CONNT* 

0 

> T S 2 G 1 0 

0 

CLASS* 

1 

TYPE = 

1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS2G10 

0 

ZNAME* 


TS2G15 




REVER* 

0 

CONNT* 

0 

> T S 2 G 1 1 

0 

CLASS* 

1 

TYPE = 

1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 
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TS2G11 

0 

Z N AME = 


TS2GX 5 




RE VER* 

0 

CONNT* 

0 

> TS 2G1 2 

0 

CLASS- 

1 

TYPE * 

1 

VALUE* 

9 

NI CON* 

1 

NECON* 

0 

t ? 

0 

ZNAME 


TS2G 1 r » 




U E V E R = 

0 

CONNT* 

0 

>T52G1J 

0 

CLASS- 

1 

TYPE * 

1 

VALUE* 

9 

N ICON* 

1 

NECON* 

0 

T S 2 G 1 

0 

ZNAME- 


T S 2 G 1 r * 




RE VER* 

0 

CONNT* 

0 

, 'IT, /() ) /\ 

0 

CLASS- 

L 

T Y P E - 

1 

VALUE* 

9 

N I CON* 

1 

NECON* 

0 

T52GH 

0 

ZNAME* 


TS 2G X 5 




REVER* 

0 

CONNT* 

0 

> TS 2G1 5 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

9 

NI CON* 

X 

NECON* 

0 

TS 2G1 5 

0 

ZNAME* 


TS 2G X 6 




REVER* 

0 

CONNT* 

0 

> TS 2G1 6 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

TS 2G 1 6 

0 

ZNAME* 


TS 2G 2 6 




REVER* 

0 

CONNT* 

0 

TS 2G1 6 

0 

ZNAME* 


TS 2G 3 6 




REVER* 

0 

CONNT* 

0 

TS2G1 6 

0 

ZNAME* 


TS 2G 3 9 




REVER* 

0 

CONNT* 

0 

> TS 2G X 7 

0 

CLASS* 

1 

TYPE = 

X 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2 G 1 7 

0 

ZNAME* 


TS 2G 2 3 




REVER* 

0 

CONNT* 

0 

> TS 2 G 1 8 

0 

CLASS* 

1 

TYPE = 

X 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2 G 1 8 

0 

ZNAME* 


TS2G23 




REVER* 

0 

CONNT* 

0 

> TS 2G 1 9 

0 

CLASS* 

1 

TYPE = 

X 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2G 1 9 

0 

ZNAME* 


TS2G2 3 




REVER* 

0 

CONNT* 

0 

> TS 2G2 0 

0 

CLASS* 

1 

TYPE = 

X 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2G 2 0 

0 

ZNAME* 


TS 2G 2 3 




REVER* 

0 

CONNT* 

0 

> TS 2G2 1 

0 

CLASS* 

1 

TYPE = 

X 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 2 1 

0 

ZNAME* 


TS 2G 2 3 




REVER* 

0 

CONNT* 

0 

> TS 2G 2 2 

0 

CLASS* 

1 

TYPE = 

1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 2 2 

0 

ZNAME* 


TS 2G 2 3 




REVER* 

0 

CONNT* 

0 

> TS 2 G 2 3 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G2 3 

0 

ZNAME* 


TS 2G 2 4 




REVER* 

0 

CONNT* 

0 

> TS 2G 2 4 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

3 

NECON* 

0 

T S 2 G 2 4 

0 

ZNAME* 


TS 2G 3 0 




REVER* 

0 

CONNT* 

0 

TS 2G 2 4 

0 

ZNAME* 


TS2G34 




REVER* 

0 

CONNT* 

0 

TS2G24 

0 

ZNAME* 


TS 2G 3 7 




REVER* 

0 

CONNT* 

0 

> TS 2G 2 5 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

X 

TS 2 G 2 5 

0 

ZNAME* 


TS 2G 2 6 




REVER* 

0 

CONNT* 

0 

TS 2 G 2 5 

0 

CSMS F = 

0 

REGNO* 

7 

BITNO* 

X 6 

REVER* 

0 



> TS 2G 2 6 

0 

CLASS* 

1 

TYPE = 

1 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2G 2 6 

0 

ZNAME* 


TS 2G 2 8 




REVER* 

0 

CONNT* 

0 

> TS 2G 2 7 

0 

CLASS* 

1 

TYPE = 

X 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 2 7 

0 

ZNAME* 


TS2G28 




REVER* 

0 

CONNT* 

0 

> TS 2G 2 8 

0 

CLASS* 

1 

TYPE = 

3 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 2 8 

0 

ZNAME* 


TS 2 FO 8 




REVER* 

0 

CONNT* 

7 

> TS 2G 2 9 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2G 2 9 

0 

ZNAME* 


TS 2G 3 0 




REVER* 

0 

CONNT* 

0 

> TS 2G 3 0 

0 

CLASS* 

1 

TYPE = 

X 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 3 0 

0 

ZNAME* 


TS2G3 2 




REVER* 

0 

CONNT* 

0 

> TS 2G 3 1 

0 

CLASS* 

1 

TYPE * 

X 

VALUE* 

9 

NICON* 

1 

NECON- 

0 

TS 2G3 1 

0 

ZNAME* 


TS 2G 3 2 




REVER* 

0 

CONNT* 

0 

> TS 2G3 2 

0 

CLASS* 

1 

TYPE * 

3 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G3 2 

0 

ZNAME* 


TS 2 F 0 9 




REVER* 

0 

CONNT* 

7 

> TS 2G 3 3 

0 

CLASS* 

X 

TYPE = 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2G 3 3 

0 

ZNAME* 


TS2G38 




REVER* 

0 

CONNT* 

0 

> TS 2 G 3 4 

0 

CLASS* 

1 

TYPE = 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2G 3 4 

0 

ZNAME* 


TS2G38 




REVER* 

0 

CONNT* 

0 

> TS 2G 3 5 

0 

CLASS* 

1 

TYPE * 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 

TS 2G3 5 

0 

ZNAME* 


TS2G40 




REVER* 

0 

CONNT* 

0 

> TS 2G3 6 

0 

CLASS* 

X 

TYPE * 

5 

VALUE* 

9 

NICON* 

X 

NECON* 

0 
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T S 2 G 3 6 

0 

Z N AME = 


T S 2 G 4 0 



R E V E R * 

0 

CONNT* 

0 

> t r; 2 r; i / 

0 

r i . A r. « 

1 

T V 1* K ~ 1 

VALUE* 

9 

N r r o n == 

1 

NECON* 

0 

T S 2 G it 7 

0 

ZN AME= 


T S 2 G 4 1 



REVER* 

0 

CONNT* 

0 

> TS 2G 3 8 

0 

CLASS= 

1 

TYPE * 1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 3 8 

0 

Z NAME = 


TS 2G 4 1 



REVER* 

0 

CONNT* 

0 

> T S 2 G 3 9 

0 

CLASS* 

1 

TYPE = 1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2 G 3 9 

0 

ZNAME* 


TS 2G4 1 



REVER* 

0 

CONNT* 

0 

> TS 2G4 0 

0 

CLASS* 

1 

TYPE * 1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G4 0 

0 

ZNAHE* 


TS 2G4 1 



REVER* 

0 

CONNT* 

0 

> TS 2G 4 1 

0 

CLASS* 

1 

TYPE = 3 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2G 4 1 

0 

Z NAME = 


TS 2G4 2 



REVER* 

0 

CONNT* 

0 

> TS 2G4 2 

0 

CLASS* 

1 

TYPE = 5 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS2G42 

0 

ZNAME* 


TS2F10 



REVER* 

0 

CONNT* 

7 

> TS 2G 4 3 

0 

CLASS* 

1 

TYPE = 5 

VALUE* 

9 

NICON* 

4 

NECON* 

1 

TS 2G 4 3 

0 

ZNAME* 


TS2F08 



REVER* 

0 

CONNT* 

-3 

TS 2 G4 3 

0 

ZNAME* 


TS 2F0 9 



REVER* 

0 

CONNT* 

-3 

TS 2G4 3 

0 

ZNAME* 


TS2F10 



REVER* 

0 

CONNT* 

-3 

TS 2 G 4 3 

0 

ZNAME* 


TS 2G4 6 



REVER* 

0 

CONNT* 

0 

TS 2G 4 3 

0 

CSMSF* 

0 

REGNO* 7 

BITNO* 

1 7 

REVER* 

0 



> TS 2G 4 4 

0 

CLASS* 

1 

TYPE = 1 

VALUE= 

9 

NICON* 

1 

NECON* 

0 

TS 2G 4 4 

0 

ZNAME* 


TS2G44 



REVER* 

0 

CONNT* 

0 

> TS 2G 4 5 

0 

CLASS* 

1 

TYPE * 5 

VALUE= 

9 

NICON* 

4 

NECON* 

0 

TS 2G 4 5 

0 

ZNAME* 


TS 2G2 7 



REVER* 

0 

CONNT* 

0 

TS 2 G 4 5 

0 

ZNAME* 


TS2G25 



REVER* 

0 

CONNT* 

0 

T S 2G 4 5 

0 

ZNAME* 


TS 2G 2 9 



REVER* 

0 

CONNT* 

0 

TS 2 G 4 5 

0 

ZNAME* 


TS 2G3 1 



REVER* 

0 

CONNT* 

0 

> TS 2 G 4 6 

0 

CLASS* 

1 

TYPE = 5 

VALUE= 

9 

NICON* 

1 

NECON* 

0 

T S 2 G 4 6 

0 

ZNAME* 


TS2G47 



REVER* 

0 

CONNT* 

0 

> TS 2G 4 7 

0 

CLASS* 

1 

TYPE = 5 

VALUE* 

0 

NICON* 

1 

NECON* 

2 

TS 2 G 4 7 

0 

ZNAME* 


TS2G48 



REVER* 

0 

CONNT* 

0 

TS 2G 4 7 

0 

CSMSF* 

0 

REGNO* 2 8 0 

BITNO* 

1 7 

REVER* 

0 



TS 2G 4 7 

0 

CSMSF* 

0 

REGNO* 2 8 1 

BITNO* 

1 4 

REVER* 

0 



> TS 2 G 4 8 

0 

CLASS* 

1 

TYPE = 1 

VALUE* 

9 

NICON* 

1 

NECON* 

0 

TS 2 G 4 8 

0 

ZNAME* 


TS2G48 



REVER* 

0 

CONNT* 

0 

> ZZZFAULTER 

1 

CLASS* 

i 

TYPE=* 1 

VALUE* 

0 

NICON* 

3 0 

NECON* 

1 

Z Z Z F AU LTER 

1 0 

ZNAME = 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

ZZZFAULTER 

1 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

ZZZFAULTER 

I 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

Z Z ZFAULTER 

1 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

ZZZFAULTER 

1 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

Z Z ZFAULTER 

10 

ZNAME* 


ZZZZ DUMMY 



REVER* 

0 

CONNT* 

8 

Z Z ZFAULTEP 

1 o 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

Z Z ZFAULTER 

1 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

ZZZFAULTER 

1 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

8 

ZZZFAULTER 

1 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 

e 

ZZZFAULTER 

1 0 

ZNAME* 


Z Z Z Z DUMMY 



REVER* 

0 

CONNT* 
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Appendix E 


Terns and Abbreviations 



Terms and Abbreviations 


Terms 


device 

simple gate, or regular gate 
device name 

device index number 

device address 

device identifier 
stack 


A gate, flip-flop or tri-state. 

An AND,OR,NAND,NOR,XOR, or NXOR gate. 

A 20-character name assigned by the user to the 
device 

An integer assigned to each device by the 
initialization program. The first device in 
the netlist is assigned the number 1, and 
integers are then assigned sequentially to the 
remaining devices in the order in which they 
appear in the netlist. 

The beginning QM-1 control store location 
assigned by the initialization program to hold 
the state description or "header word” (see ()) 
for the device. 

For the Vax: the device index number 
For the QM-1: the device address. 

A list of device index numbers(for vax 
emulator) or device addresses (for QM-1 
emulator) of those devices whose output values 
changed during the previous time step. 


Abbreviations 


ei 

eo 

cs 

ms 

*filename 


external inputs 
external outputs 
control store 
main store 

User Prefix followed by rest of file name 




General Notes 


Device Names 
Fortran Formats 

Radix Notation 


The user must enter a device name in Upper Case in every 
instance in which it appears in any input file. 

It is assumed in the descriptions of the input files to the 
emulator programs that the user is familiar with Fortran 
Format statements . 

All numbers in this document are assumed to be decimal, 
unless the radix is specifically noted, for example, 
"octal”. 


E - 1 



NASA 

National Aeronautcs and 
Space Administration 


1. Report No. 

NASA CR-1 78391 


4. Title and Subtitle 


Diagnostic Emulation: 
Implementation and User's Guide 


Report Documentation Page 


2. Government Accession No. 


3. Recipient's Catalog No. 


5. Report Date 

December 1987 


6. Performing Organization Code 


7. Author! s) 


Bernice Becher 


9. Performing Organization Name and Address 

PRC Kentron, Inc. 

Hampton, VA 23666 


12. Sponsoring Agency Name and Address 


National Aeronautics and Space Administration 
Washington, DC 20546-0001 


8. Performing Organization Report No. 


10. Work Unit No. 

505-66-21-03 


11. Contract or Grant No. 

NASI -18000 


13. Type of Report and Period Covered 

Contractor Report 

14. Sponsoring Agency Code 


15. Supplementary Notes 


16. Abstract 

The Diagnostic Emulation Technique was developed within the System Validation 
Methods Branch as a part of the development of methods for the analysis of the 
reliability of highly reliable, fault tolerant digital avionics systems. This 
is a general technique which allows for the emulation of a digital hardware 
system. The technique is general in the sense that it is completely independent 
of the particular target hardware which is being emulated. Parts of the system 

are described and emulated at the logic or gate level, while other parts of the 
system are described and emulated at the functional level. This algorithm 
allows for the insertion of faults into the system, and for the observation of 
the response of the system to these faults. This allows for controlled and 
accelerated testing of system reaction to hardware failures in the target 
machine. This document describes in detail how the algorithm was implemented at 
NASA Langley Research Center and gives instructions for using the system. 


17. Key Words (Suggested by Author(sl) 

Fault tolerance 
fault simulation 
logic simulation 


19. Security Classif. (of this report) 


Unclassified 


NASA FORM 1828 OCT 86 


18. Distribution Statement 

Unclassified - Unlimited 


Subject Catetory 66 


20. Security Classif. (of this page) 

21. No. of pages 

22. Price 

Unclassified 

172 

A08 















